How much DakarPerformance can we reasonably expect to achieve? All of the benchmarks and tests surrounding Cairo are focussed on how much worse it is than AthensRelease. However I really want to know is how much better could it be than Athens? I don't think Athens perf was all that hot myself.

-- MattWilkie - 15 Sep 2004

I've dredged through a lot of the code now, and found some right howlers. Based on simply recoding fragments of the current code and reaping dead and duplicated code I think we can achieve ~30 AthensMarks. Rather depends on whether we can find perl experts to review the code and spot the howlers.

As they say in the marketing department, it's not what you sell, but how you sell it. Greater performance can be 'achieved' through judiciously making certain functionality optional - for example,

• disabling plugins in the release
• moving %TOC% into a plugin
• making the whole protections scheme a plugin
• Stop slavishly supporting %VARIABLE% expansion for every Set.

I think we can get back to ~80 AthensMarks doing this.

To go beyond that requires refactorings which will change the semantics of TWikiML, because they require recoding the core rendering loop. That should get us to 100 AthensMarks, but I doubt it would take us beyond.

Wholesale refactoring to a TopicObjectModel might take us slightly further; say 110 (guessing)

IMHO to go beyond that requires a major technology shift e.g. a different implementation language or recoding key sections in C.

Just my opinion.

-- CrawfordCurrie - 15 Sep 2004

TWiki's performance is in stark contrast with Wikipedia and XWiki, that work with a database backend. Would a database be an option for TWiki?

-- ArthurClemens - 15 Sep 2004

So just for clarity: you think that with a lot of work Dakar might be able to equal Athens performance. While better-than-Athens will not happen without a radically different substrate. (?)

So we could say then that "Dakar is ready for release when we've achieved 50% of Athens performance?" I'm trying to pick a number which would allow a new stable release in less than year.

-- MattWilkie - 16 Sep 2004

While it's nice to have release goals of either when we've got X% performance or after Y months, I think it would be better to release when it's clear that any more performance gains or feature improvements are going to take significantly more effort than for the gains already made.

-- SamHasler - 17 Sep 2004

Arthur; yes. I've been shot down in flames enough times for suggesting it that I didn't even bother. But a database backend could make a signficant difference. However I see that as a "major technology shift".

Matt, yes. Just my opinion, of course.

Sam, I think it will never be "clear" - perl is so complex and unpredictable that the wierdest and most unintuitive small change can make a significant difference to performance.

My personal preference is to set a date target. Say we will release Dakar on Dec 1 come hell or high water, and that it will be focused on performance and not features.

-- CrawfordCurrie - 18 Sep 2004