I did a profiling run of fr versus en, at:
http://meta.wikimedia.org/wiki/Profiling/En_versus_fr
Note that the total times are skewed by a single slow query recorded on fr. The specific functions provide a better comparison.
Brion Vibber wrote:
fr might in fact be very slightly slower than en since it loads a second language file and the UTF-8 support functions & data. (This will be mostly eliminated once en converts to UTF-8 someday.)
The second language file would show up in Setup.php-language, and indeed it does: 2.05ms for en versus 27ms for fr. I think the ucfirst function would show up in Title::secureAndSplit(): 790us each for fr versus 250us for en. However that's not a very big effect, and in fact the overall Article::view() time for fr is faster than that for en: 146ms versus 110ms. I'm not sure exactly where that discrepancy comes from. This was taken in an off-peak period.
However all speed is extremely variable on these wikis, and depends on the load of the servers, how much you've got cached, whether you're logged in, whether the page is cached in the parser cache, the complexity of the pages involved, whether there are templates, whether the templates are cached, whether you have new messages, whether there's a site message, whether your user data's cached, and the phase of the moon. The absolute speed difference will be *dwarfed* by the hit-to-hit variations.
It's important that we serve the non-en wikis consistently faster than en, and I'd welcome any technical suggestions on how to do this. This is because when fr is faster than en, it's because developers only care about en and the other languages are just along for the ride. Never mind the fact that 11 out of the 17 people with shell access are from Europe, as are almost all of the regular CVS committers. When fr is faster than en, it's because en is bigger than fr and therefore harder to serve.
Perhaps this would do the trick:
if ( $wgLanguageCode == "en" ) { sleep(1); }
-- Tim Starling