VBulletin is written in PHP and uses MySQL. DCForum is written in Perl and uses flat files. The language and data retrieval, however, weigh in very little in the final decision.
I don't believe Perl is a poor choice for data intensive applications. Poorly implemented Perl is (UBB) a poor choice. 90% of application bottlenecks can usually be traced to poor code. Perl can interface quite nicely to SQL databases (though SQL is not a cure all). SQL queries can be written poorly, enough so that flat files are faster. SQL also does not insure against data loss.
DCForum is wonderfully done (in Perl) and on the FTE site, which has more CGI traffic than TDR, CPU usuage by DCForum is under 2%. I'm sure with mod_perl it would use even less. I'm evaluating VBulletin right now to see how it compares.
I do not base any of this on guesswork but experience. I've been a professional programmer since 1986. I have 6502, 6809, 68000, 8080, Z80, 80x86 assembler skills. I've programmed in C, C++, Visual C++, Perl, Pascal, Java, Javascript, Visual BASIC and in the process of learning PHP. I've used several databases, most notibly Oracle, Sybase and MySQL. Recent OS experience on Linux, NT/95/98 and Solaris. I've done everything from fault tolerant network coding to accounting.
While some languages are better suited for certain tasks than others, no language will do the trick if the code is poor done. UBB lumps all its code in about 4 modules. Each of these has to be loaded and tokenized every single time a page is clicked on the boards. DCForum splits its code in about 115 small files, each of which accomplishes only one or two tasks and is loaded on as needed. VBulletin uses PHP. Not sure how fast it is compared to Perl, but the backend is MySQL. VBulletin is supposed to be able to import UBB data but I've heard that there are some problems with the import.
Our primary concerns are features, efficiency, ease of maintenance (read: coding additional features), support and active development by the development company. Being able to manage TDR's need (ie, handling membership in an efficient manner) is also a big concern. UBB does not work well when it comes to managing membership.
-Ken
[This message has been edited by ken (edited 12-17-2000). ]