We did a lot of work on the build engine for FinalBuilder 4, mainly in the area of performance. It's not like the performance of the FB3 build engine is slow, but there is always room for improvement! The basic architecture of FinalBuilder is that there is a build engine (produces messages), a message queuing system, the user interface (subscribes to the messages), and the logging sub-system (which also subscribes to the build messages). All of these run in their own thread. The build engine and messaging systems have code in them to force context switches to other threads and also to sleep for a while to allow the other threads to breathe. One of the problems with this is that sometimes the sleeps are too long, and sometimes they're too short - and these depend on many factors, eg. CPU speed, number of CPUs, the volume and type of messages coming from the build engine, the overhead of other tools which the build engine is calling, etc.
When the sleeps are too long the build time suffers; when the sleeps are too short it's possible for the build engine to be ahead of the UI and the logging. We have done some experiments where the UI would take over 30 mins to catch up to the build engine because of the enourmous volume of messages still left in the message queues.
One technique we experimented with was to dynamically change the sleep time depending on the CPU load. We query the CPU and get it's load and then calculate a sleep time depending on the load and the last sleep time - the target was about 95% CPU load. We tested it on a variety of machines, all of different speeds and it worked reasonably well - was generally faster than FB3 in most situations, but was still not optimal.
The technique we ended up with is very simple - calculate the total amount of messages in all the internal messages queues and sleep until the total amount of messages is below 10. (almost too simple, eh). This change has the effect that we never sleep for too long (ie. don't waste CPU cycles), and the build engine waits until almost all messages are processed, meaning the build engine will never get a long way ahead of the UI and Logging. The net effect is that build times in FB4 are shorter, and the UI and Logging is never behind the build engine.