OK, I ran the full flexwiki.com corpus tests against the latest build last
night. Here are the results:
. As I've said before, it's pretty hard to give a single number to
the performance, since some pages are faster and some are slower.
. Average page execution time in FlexWiki 2.0 is now down to about
550ms on the third iteration. The first iteration is down to 600ms or so,
which is comparable to the first (and - oddly - fastest) iteration in 1.8.
Recall that over time 1.8 gets slower in my tests.
. Sorting by average page execution time across all three
iterations, FlexWiki 2.0 is faster than one second 96% of the time, faster
than two seconds 98.5% of the time, and faster than five seconds 99% of the
time.
. That means that just 21 pages out of 1862 tested averaged slower
than five seconds. Of these, a couple appear to be slow because they
followed immediately after some pages that were so slow that the request
timed out and the CPU was still busy when the next request was made.
. Of the pages that were slower than five seconds, only five were
more than twice as slow as FlexWiki 1.8. Of these, two appear to have been
slower because of the CPU-eating problem I just mentioned.
. Here are the three remaining pages:
Topic
1.8 average time
2.0 average time
Notes
BlikiCommentsPlugin
1365ms
16252ms
Initial run very slow (46s): page ran at 1.2s in last two iterations.
CharacterTest
1351ms
11810ms
No WikiTalk. The big culprit here appears to be RegEx.Replace.
CrapCollectorScript
2556ms
8421ms
First run of 1.8 is 6750ms. Lots of WikiTalk.
. LPTest is the page that I suspect of being so slow that it times
out. Here's the body:
@@
namespace.TopicsWith("Nearby").SortBy
{ each | each.Name }.Collect
{ each | ["%small% ",each.Name," %% ",Newline]}
@@
@@
namespace.Topics.Collect
{ each | each.PropertyNames }.Collect
{ each | [each] }
@@
Obviously, that's some fairly serious WikiTalk, although I'm not entirely
sure why this is so much worse than other places where WikiTalk is employed.
. If you just sort by the pages that are slowest on the third
iteration of 2.0, there are 18 slower than 5 seconds. Of these all but three
are significantly faster than 1.8. These are CharacterTest,
CharacterReferenceTable, and CrapCollectorScript. So the same ones as above,
basically.
Analysis
I feel like performance is pretty good. We've got one page which unusable,
but it's degenerate: it iterates every property of every page. The rest
execute in a reasonable amount of time. Overall, it's faster, and generally
it's only slower for pages which use *heavy* WikiTalk.
I still want to hear David's results, as well as comments from anyone else
who's run this, but barring any showstoppers I don't see any need to
continue optimizing, especially as the next step for optimization would be
fairly difficult to pull off. Again assuming no showstoppers I say we fix up
the remaining admin UI TODOs and ship this sucker.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flexwiki-users mailing list
Flexwiki-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki-users
