Hi,
It looks like when doing a build (“Run Simulation) the build is using a “write thru to disk” command rather than a “write to memory (DRAM) style command, which makes build times take several minutes instead of a few seconds. I observed this by noticing that doing a build on a lowly netbook and a high end quad-core server, took almost the same amount of time and that the Disk I/O was “maxed out”.
Can you please correct “whatever” is the source of this many minute build time problem in the next release? This slow “run simulation” time is killing productivity.
Thank you in advance!
3 answers
In order to run the simulation in web browser, we have to save all files on the disk.
The build time would be long if your plot is complex, but if it take several minutes, that’s too much. Maybe the image dock contains too many images. You can check the size of your .4ui file, if it is bigger than 200KB, it is most probably contains many (big) images inside.
You can take a look at the image dock, and check if there is any image that is not actually used. You can remove those unused images to reduce the plot file size, and the build time should also be cut down.
Another possibility is the duplicated image reference, you may find duplicated images in the image dock. You can merge them with the “Change Reference to…” button.
In our TODO list, there is a feature that can auto clean up the image dock, the unused image can be removed after user’s confirmation, and duplicated image reference can be merged as well.
I made a rather complex prototype about 8 month ago, and it took 1-2 minutes to build. If it’s a “normal” sized prototype (less than 10 pages) it doesn’t take many seconds.
How many pages does your prototype contain?
I’m running ForeUI on a 2,0 GHz Core2 Duo with 4 GB of RAM.
Hi Kenneth,
Actually we could not decide the number of files that should be generated. The “building” process have to generates some HTML, CSS, JavaScript and image files that can be loaded in web browser and run the simulation. You can regard all these files as a web site, we could not build a website with just one big file.
Since the final product (many small files) are necessary to run the simulation in web browser, no matter what solution we use, we must write all these files into disk (one by one). So I think the disk I/O can not be saved without simplifying the plot.
This question is now closed
Thank you for the prompt reply. I will check out the image dock idea, but that is a minor time impact.
I believe the real issue is that ForeUI appears to create "hundreds" of very small files and it "writes each file to disk one at a time as they are created" versus an alternative method of writing the files "all in one shot at the end of the build". This alternative method, could even be combined with creating "one big file" during the build and then writing a "single file to disk" at the end of the build. Either would dramatically improve the massive disk I/O resource hog that ForeUI is during the build process.
Perhaps there is something else going on that I don't understand, but maxing out the disk I/O for a build process is NOT NORMAL in coding. Your team should look into alternative methods as this is a significant time impact on verification cycles on complex models..
Thank you in advance.