Sure!
Ehm, the number indeed seem to be correct, always difficult to have the exact same conditions!
The parser indeed performs much better, keep in mind that a lot of stuf is behind our hands, so the total processing time gain for a page is not 45% !
While working on the parser I thought a bit on the caching thing.
It’s obvious that a "true" cached page (no merging of snippet that needs still to be processed) is the fastest way of serving a html page.
It seems the [! !] call convention was made to have semi-cached pages. The content was cached, but the snippets were still executed.
However, this is very confusing to use, and error prone IMHO.
The user has to be aware that both calling a snippet like [[ ]] or [! !] has different effects, but also, when creating a page, he/she has to think about "do I want this page to be cached or not", and what effect does it have with the current template and the way the snippets are called there etc ?
So, the fastest way to serve a page is to take it from cache, and the easiest way for the user is to not bother about caching at all!
So, one calling convention for snippets/chuncks/etc and (perhaps) a global configuration parameter "enable/disable cache". (I’m thinking for those people having a NUMA system with 16 processors and 128 Gig of RAM but are going out of hard disk space hehe :-P )
With one calling convention, the user doesn’t give the parser a hint if there can be done partial caching or not. I actually think, with one way to call snippets/etc there is no way to determine if a snippet output has to be regenerated or can be taken from cache.
Why?
Well, a snippet can depend on _any_ data inside the database, so there’s no way to say "this part in the database has changed, so we need to regenerate snippet X’s output".
This however could be done perhaps for chunks, and others, but not for snippets.
So, I suggest that by default, a page output is cached with a timestamp when it was created.
Now, if the database changes, that time is written to a file, and when we check for a cached page, we compare these two values.
If the database is newer, we generate a new page, and overwrite the old page cache for that particular page......
This means that at least for snippets there is no more partial caching, perhaps chuncks can be cached (seperataly) easier....
What do you think about this?
Remon
P.S.
[! !] worked by replacing those with [[ ]] at the last stage and running the parser again on the source. We could still use this, but I don’t like it, and it doesn’t confirm to the calling standard
P.S.2
Just popping up into my mind.
What if we "pregenerate" the page on document creation/modification, and cache it _without_ the snippets/TV’s processed?
But then, why not generating the whole page at once?
End then, why do we have a parser at all? ;-)
I need to go to bed, since I obviously miss something here....