Brion Vibber wrote: That's a very long time. Is there any chance you can post some more fine-grained timings (perhaps profiling output) for these pages? What of the three seconds is network latency, what's overhead, and what's parsing?

Brion Vibber wrote: <snip>depressing time statistic</snip> If there ever was need for a C++ parser... ;-)

Yup, that function's new (didn't see it a few days ago). Seems the most time is spent in database queries. Not much to do about that except caching, which we do. We could collect the links to use one big query instead of several ones, maybe?

Brion Vibber wrote: Didn't see your previous mail, or looked at the function very carefully. I still didn't, so is every occurrence in $string unique? If so, why not use $this->mBodytext = str_replace( $search, $replace, $this->mBodytext , 1); (note the ",1"; maybe it should be "count($search)", I'm not sure) Thus, if one replacement is shown, it won't have to search the rest of the string. Magnus _______________________________________________ Wikitech-l mailing list Wikitech-l(a)wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Brion Vibber wrote: I've added some smaller profiling cunks in that functions: [snip]

Jens Frank wrote: Median page view time for this page on 1.3.1 with $wgEnableParserCache is 346ms as measured with ab on the same machine. At this point a dominant time sink is loading and parsing the PHP files (I haven't installed a PHP cache module on this machine), and skin building output and buffering/sending of raw output become significant as well. Major offenders from profiling output: -total 1 277.770 277.770 100.000% Setup.php 1 151.931 151.931 54.697% Skin::outputPage 1 102.973 102.973 37.071% OutputPage::output 1 103.143 103.143 37.132% Skin::doAfterContent 1 63.289 63.289 22.785% wfMsg 53 50.454 0.952 18.164% Skin::quickBar 1 34.159 34.159 12.297% Skin::doBeforeContent 1 27.438 27.438 9.878% Article::view 1 18.326 18.326 6.597% So clearly we've gone backwards on at least some cases by doing link replacement after the parser cache. (A very short page with no links renders slightly faster with 1.4-cvs than on 1.3.1.) -- brion vibber (brion @ pobox.com) ------------------------------------------------------------------------ _______________________________________________ Wikitech-l mailing list Wikitech-l(a)wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Magnus Manske wrote: Neat! But now that I look at it, it can be sped up a lot just by using a regular expression: Original str_replace method: 1 4260.353 4260.353 44.304% Magnus' scary hack: 1 423.490 423.490 7.385% Using preg_replace_callback: 1 21.842 21.842 0.354%

Jens Frank wrote: Unfortunately no; it takes out a big chunk but it's still slower. This brings the full Village Pump page load time on my Linux box from 1501ms down to 901 ms, compared to 340 ms on 1.3.1. (Both with memcached and parser cache active; times are median total per-hit load time measured with 'ab -n 10' on the local host.)