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