Application Speed - UI configuration

[KristanStewart]

I'm doing some speed testing on our build and build script.

Currently i'm trying to get some baseline information on the current speed of the script with small configuration changes. I'm also trying to get a benchmark for any affect VisualBuild itself might impose on the script execution depending on it's configuration.

Couple of questions:
I've noticed if i have the build output window visable the build machine can 'bog' down when displaying a lot of info to the output window in a short amount of time, is this likely to affect the execution speed of the script itself?

Is the script likely to respond faster/slower if:
- The build output window is displayed/sized to nothing
- The application is minimized
- The commandline exe is used instead of the GUI exe

I'm trying to come up with a 'standard' execution config for the build speed tests to give any speed tests on changes a fair start against the old script.

Ideally I'd like to run the script using the GUI exe to save time and ease debugging/working with the script (eg continuing from failures).

[kinook]

What exactly do you mean by "bog down"? The console app will be quicker than the GUI app (although we haven't done any comparative timings to say how much of a difference). Some things that could affect the speed of a build:

* GUI vs. console app
* /nooutput flag (console app)
* 'Tools | User Options | Output | Maximum length of output pane' (GUI app)
* File logging and options (Tools | Application Options | Logging)
* active scanning anti-virus software (esp. if file logging is enabled or the build does a lot of file generation/copying)

[KristanStewart]

Thanks for the suggestions. I hadn't noticed the Maximum length of output pane option.

By "bog down" i mean, graphical resources on the machine will be inaccessible (switching between applications, minimizing/maximizing windows, basically interating with Windows in a graphical manner). This normally occurs when the script is executing 'tight' (meaning going from step to step very quickly) if I resize the output window to nothing the ui problems stop and I can use Windows as normal.

[kinook]

I wasn't able to reproduce any bogging of the Windows UI running a continuously repeating build loop, even with the default options and Output pane configuration. Running the build at a lower priority (using the Set Priority action) might make a difference. What version+SP of Windows and hardware are you running on?

[KristanStewart]

We're using Windows XP (SP1 and Sp2) boxes.
Typically 3GB+ CPUs with 2 GB of RAM. I've only noticed it on buildscripts that have been running for a long while (4-8 hours). I checked the settings for line numbers in the Build View and it was set to 10000 so that could have something to do with it.

Generally I see it when the output view is scrolling a lot (it looks like it's scrolling from the top to the bottom of the build view with every write to the build view)

We're currently using VisualBuild 5.7 but we're upgrading to 6 soon.