Slow?

[magwo]

Hello,


why is Visual Build so very very slow when executing build scripts? It seems to me that a delay has been put somewhere in the stepping code so that the user will be able to follow the steps properly - which is fine, until you start using VBP to do for-each-file steps with several hundred files and so on. It takes a LOT of time, considering we do it 10-15 times for each build in total.


I've seen suggestions to run VBP without logging from a console command. But this isn't really what we want either - we still want to be able to follow the build process and pause/continue it properly if something isn't right.
We simply would like it to perform steps much faster.


As I see it, the sluggishness can't be the result of computationally expensive steps, but rather a delay (sleep or similar) put in the stepping code to prevent the build process to run incomprehensibly fast. It seems strange to me that the very trivial operations that VBP perform would take several hundred milliseconds to complete.


The consequence of this slowness is that we're continually moving steps out of the build process into Python scripts that perform well. Ultimately this might cause us to move away from VBP due to it losing its role as a vital part in the build process.

[kinook]

Is the slowness you're encountering specific to Process Files steps with many files? If so, this thread discusses some reasons why using that will be slower than actions that process masks directly:
http://www.kinook.com/Forum/showthread.php?threadid=466

Please ZIP and send or post:
1) The info from Help | About | Install Info
2) The .bld file demonstrating the slowness (indicating which steps are slow)
3) A build log file

Thanks.

[magwo]

The Process files step isn't exceptionally slow - the problem is the time it takes VBP to complete a step (the overhead) - pretty much any step. I estimate that it takes about 200-300 milliseconds to complete common steps in VBP. This is ridiculous, as corresponding operations in Python or other script languages probably would take less than a single millisecond to complete.

As an illustrative example: Let's say we have 200 files that need to be processed. And we do the build process 15 times with different variables each run. Each file in Process files results in two steps in VBP (iteration and the actual operation). 0.25 seconds*2*200*15 = 25 minutes, which is unacceptable. I estimate that the corresponding operations done in python would complete in a few seconds tops.


Us sending you the build script and related files would not clarify things - as it is the inherent overhead of the per-step execution of VBP that is the actual performance problem.

[kinook]

Timing execution of one statement in a scripting language vs. one step in the VBP GUI is like comparing apples and oranges. VBP provides a multi-threaded, extensible build environment (extensible at runtime via scripting events, custom actions, build rules, macros, custom logging components, live visual display of build progress and output, etc.), and all of this infrastructure adds functionality, as well as overhead, to the process.

A better comparison would be to run the VBP console app with no file logging or build output (i.e., visbuildcmd /nologo /logfile "" /nooutput abc.bld). In tests here (AMD 64 X2 CPU, 2GB RAM, fast hard drive) with a Process Files step and child Log Message step that iterate over 2,700 files (5,400 step iterations), such a build completes in about 2 seconds, which works out to well under one millisecond per step.

By far the largest overhead is building via the GUI app (which logs build output to a GUI window, displays current step build status live, allows for pause/continue/abort, single-step debugging, etc.), so if you can use the console app to build, projects with many iterating steps will run much faster.

There is no explicit throttling of build execution. You're the second person ever to complain about VBP build performance, and we will bump the priority of investigating to see if any further optimizations can be achieved.

Some reasons we were interested in seeing your build script was to possibly
1) identify ways to avoid multiple iterations over the same files
2) recommend the use of newer VBP file-related actions that perform iteration internally
3) determine all reasons for slowness (whether due to overhead of VBP itself, individual step processing, logging, etc.)

[magwo]

Ok,


when we run the build script from the console with logging ENABLED, it runs about three times faster than in the GUI (16 seconds vs 49 seconds). So the major bottleneck is the GUI stuff, which is responsible for approximately 2/3 of the time needed to complete a step - not the multi-threaded extensible scripting environment.

Disabling logging for our console build has very minor effects on the build time.


However, I am glad that your are acknowledging this problem. I believe you need a feature in VBP that could gray out the steps that are currently iterating, and only update the GUI if the iteration halts. That way, the steps could be performed in a tight loop without theneed to perform time-consuming redrawing of GUI elements.

[kinook]

Try this test build, which implements significant performance improvements when building via the GUI app:
http://www.kinook.com/Download/VisBuildProBeta.exe

See here for more details on changes in this build so far:
http://www.kinook.com/VBP/beta.html

[magwo]

Excellent.

A co-worker has tried this new version and is very satisfied with the performance improvement - roughly a three-fold increase in execution speed.

Well done!