Forget all the hype. According to Microsoft's internal surveys, C++ is the most popular programming language "after HTML and JavaScript." HTML and JavaScript aren't exactly general-purpose compiled languages, so C/C++, in 2006, is still in the lead.

What makes C++ so popular today, in spite of its younger and seemingly sexier rivals? Performance is certainly a crucial criterion. Top-notch optimizers combined with the latest template metaprogramming techniques enable a C++ application to finish executing before the latest JVM/CLR is even loaded into RAM.

Yet, one area is left wanting: compilation speed. Roughly speaking, the faster a C++ app gets, the longer it takes to compile. In large scale projects, a full build can take hours; as the project advances, the long build times become critical.

Several compilation boosting technologies are now targeting this problem, including JomiTech's TwineCompiler 2.0.6. TwineCompiler is a C++ compiler wrapper that decreases compile times on single processor, multiprocessor and multicore machines. The current 2.0.6 version is designed for use with Borland C++ Builder 4-6 or Borland Developer Studio 2006. JomiTech says it will support Microsoft's compilers and IDEs shortly. Unlike other products that distribute compilation across different computers connected to the same local network (Xoreax's IncrediBuild 2.60 for instance), TwineCompiler targets a single computer.

During the painless installation process, TwineCompiler automatically detects the IDEs and compilers installed on your computer. I have both Borland C++ BuilderX and C++ Builder 4.0. I keep good old C++ Builder 4.0 for compatibility tests, while using BuilderX as a reference compiler (along with Microsoft Visual Studio 2005).

TwineCompiler detected Borland C++ Builder 4.0 and added itself to the Tools menu. To use TwineCompiler with C++ BuilderX, you need to enable it explicitly by adding Project -> Build Options Explorer... in the "set build tool set command" dialog box, and replace bcc32 with mtbcc32.

After the installation, a new option ("TwineCompiler Options...") appears in the Tools menu. TwineCompiler automatically selects the most efficient options it deems appropriate for your system, but you can alter the settings easily if you disagree. For instance, you can force background compilation or automatic cleanup of cached files before every compilation session. In addition to the new option under the Tools menu, TwineCompiler also installs an icon on the system tray.

Tip: You can disable TwineCompiler temporarily by unchecking TwineCompiler in Components -> Install Packages.

My firewall warned me of an alleged attempt to contact the Internet; this turned out to be a false alarm. JomiTech's tech support assured me that the two components installed (the IDE add-on and the executor on the system tray) use TCP/IP to communicate with one another; that led the firewall software to suspect that they were trying to access a remote site.

Personally, I find this split between a system tray executor and an IDE add-on confusing. I guess it's one of those design decisions that seem appealing on the drawing board but later disappear as the product matures.

Test Drive

My initial attempt to build a project with TwineCompiler failed. I received two cryptic error messages that didn't say much about the nature of the failure. It was obvious that the source code itself wasn't the culprit, because the code compiled without a hitch with TwineCompiler disabled.

I contacted JomiTech's tech support. They replied promptly, asking me to send them a few log files. The offender was a spurious character in C++ Builder's configuration file. I was instructed to delete this file, to no avail — this file was regenerated automatically, with the funny character in it. The solution arrived a day later in the form of a new TwineCompiler executable that didn't use this jinxed configuration file. At last, I was able to test drive TwineCompiler.

I started with a relatively small project, containing about 10,000 lines of code. A typical compile-and-build session without TwineCompiler takes less than two seconds. With TwineCompiler enabled, I didn't notice a statistically significant reduction in build time, nor had I expected it to happen. My goal was to ensure that I was still getting the same executable with TwineCompiler.

Many project managers are wary of upgrading old compilers or changing the project's settings, because a seemingly innocuous change might introduce compilation errors or bizarre runtime crashes that haven't been witnessed before. In this regard, you can relax. TwineCompiler keeps the same command line options, configuration settings and source file organization. It expedites the compilation process by using more of your CPU's power, caching files in the system's RAM etc. You can think of TwineCompiler as gasoline with a higher octane rate.

Compilation time is affected by various factors, including the number of source files in a given project. The latency incurred by opening multiple files, loading their contents into RAM, and closing the the files increases the overall build-time.

After a successful baptism of fire, it was time for a more serious project. My test project had 29 source files, with a total of nearly 50,000 lines of code.

Without TwineCompiler, compilation and build took 7 seconds. It doesn't sound like a long wait, but when you have a busy multi-user machine that serves a team of developers, compilation time gets frustratingly longer. With TwineCompiler enabled, it was reduced to 3.58 seconds i.e., a reduction of 50%, although I was using a single core processor. If you're using a dual core processor, the results are likely to be more impressive. To make sure that the speed boost was attributed to TwineCompiler and not to chance I repeated the test, with and without TwineCompiler. TwineCompiler certainly deserved the credit!

What about large-scale projects that have a smaller number of source files? Library writers often work on very large files that contain thousands of lines. In this case, the compilation latency isn't caused by file I/O as much as by parsing, syntactic analysis, and code generation phases. I tested a project of 50,000 lines spread across 5 translation units. This time, the difference was less drastic: 3.60 seconds without TwineCompiler, versus 2.90 with TwineCompiler, or a 20% reduction.

Although it still suffers from some infancy problems, such as the lack of a detailed reference manual and a confusing split between a system tray executor and an IDE add-on, TwineCompiler does cut compilation and build-time. I suspect that future versions will offer even more impressive performance improvements.

Still, this isn't a product for everyone. At present, TwineCompiler only works with Borland's compiler and IDEs. Besides, in very-large scale projects, there is always the option of upgrading hardware. I know that many project managers would prefer to throw more hardware at the problem (regardless of cost) because they are reluctant to make any changes to their software. However, if the long compilation time is an issue in your team, and you are willing to dedicate a few hours for studying and installing TwineCompiler, you should give it a shot. At $80 for a full version, TwineCompiler could be the most cost-effective investment you make.