|
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.)
|