> Hi, first thanks for the work, here... I think that your last set of > changes did it for me as far as getting back to (actually beating) 1.8 > performance. I think that I said earlier that my average ttfb for my > test case was 1370ms. Right now I get 1290ms using the latest drop.
That's consistent with what I'm seeing. Against the FlexWiki.com corpus I'm using, I see the following: 1.8 iteration 1: 613 1.8 iteration 2: 910 1.8 iteration 3: 1281 1.8 average : 935 2.0 iteration 1: 761 2.0 iteration 2: 730 2.0 iteration 3: 726 2.0 average : 739 Overall average: 837 So it's definitely better, although again 1) This is an average over all pages, which probably isn't a good metric. 2) It's against the flexwiki.com corpus, which is atypical. 3) The best FlexWiki 1.8 average is better than the best 2.0 average. 4) 2.0 appears to improve over time - 1.8 appears to decay over time. 5) Some of the times in here (particularly the long ones) are for pages that have a redirect to an external site. These should be removed from the analysis. So I'm happy with this, but I think more analysis needs to be done. In particular, I need to go in and figure out which pages are still really slow, and why, and see if we can do anything about it. > Of course, it doesn't quite compare to the 300ms that I get when I > change up my plugin so that it can filter before the sort ever takes > place. Any thoughts to the two methods I came up with for allowing > this? (expose the CompareModifiedTimes delegate and/or allow AllTopics > to accept some sort of filter delegate). > > Anyone see any reason for me not to add this? It's always quicker to > not do work than optimize the work done, and this would let me do > this. I don't think I totally understand what you want to do. Can you explain in a little more detail? I'm slightly cautious about changing anything in the core, because although the changes are probably straightforward, there could be a substantial impact on tests to be written. Also, the compositional nature of the content pipeline means that - depending on exactly what you want - doing things like exposing the CompareModifiedTimes delegate might be problematic. But I could see the filter delegate on AllTopics being reasonable to implement. I think that we should also think hard about whether this belongs in 2.0 or 2.x. Not because we have a deadline...but because we don't. :) I.e. with no external pressure, it would be fairly easy for us to sit around polishing the thing until 2009. But perhaps we can figure out something easy that will have a big impact. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
