Item10316: Stop INCLUDE from wasting CPU
Current State: Needs Developer
Released In: n/a
Target Release: major
Every occurrence of an INCLUDE
macro re-parses the entire included topic all over again, every time
for sections & boundaries. This makes delayed sectional includes in formatted searches unnecessarily painfully slow.
This task may go nowhere. At very least I'm adding some unit tests. 1.2 scope only.
I'm entertaining the thought of introducing some sort of
. There will be a feature proposal if I think I can pull this off.
- 03 Feb 2011
- 03 Feb 2011
Also: Make the _DEFAULT= (topic) parameter optional (separate task)
- 05 Feb 2011
Any progress on this one? It might be a good idea to be more specific which feature this implements some of the 4 listed above are kind of dead / rotten over time like RegisterSectionTagHandler
. People once interested in the feature did not materialize any longer.
- 12 Jul 2011
I've got a git branch somewhere with this work, but then I got stuck.
The dumbest implementation is to just replace calls to parseSections with a wrapper function that stashes the result in a hash somewhere so that parseSections is only called once per Foswiki request. This proves quite effective, but my first attempt did not consider revisions.
Then, I got bogged down moving things around: the
cannot usefully cache the parsed sections, because we create many throw-away
. The 'cache' has to live somewhere with a wider scope.
And we have to be careful to invalidate the cache on a given
if somebody adjusts the text on it.
Then I got bogged down with where to put things: I know I want a
but I am not sure where to put the parse/cache management (Store? Meta?...) - adding a WaitingFor
sven/crawford to see what they think. I've got some slow pages that are helped substantially with section caching
- 13 Jul 2011
What's the state of this? Does it need to be completed for 1.2, reverted, or left incomplete?
- 02 Jun 2014
The checkins are all to the unit tests. Deferred to 2.0.
- 04 Jun 2014