On 11/04/11 06:32, Platonides wrote:
Roan Kattouw wrote:
2011/4/9 Platonides<Platonides(a)gmail.com>om>:
Yes. Calling a template twice will only fetch the
text once, won't
increase the 'used templates' counter...
Preprocessing of wikitext over a threshold is cached serialized (it's
easier to reprocess if it's too small).
To clarify: there's an in-process cache, like Brion said, so a
template that is used twice on the same page is only fetched and
preprocessed once. However, this only applies to templates called with
no parameters. If the template is passed parameters, this in-process
cache won't be used, even if the same set of parameters is used twice.
I don't think so. The preprocess-to-tree is always the same, regardless
of the parameters, and it is always used. It is the expansion where
parameter change. I don't see that cache for parameterless templates,
maybe it's the mTplExpandCache?
The stages are basically preprocessToObj() -> expand() -> internalParse().
preprocessToObj() is the parsing stage of the preprocessor. It is fast
and easily cachable. It produces an object-based representation of the
parse tree of the text of single article or template. This object
representation is stored in a cache ($wgParser->mTplDomCache) which
exists for the duration of a single article parse operation. It
depends only on a single input string, it does not expand templates.
There is a persistent cache which stores the result of
preprocessToObj() across multiple requests, however this provides only
a small benefit.
expand() is slow. Its function is to take the parse tree of an
article, and to expand the template invocations and parser functions
that it sees to produce preprocessed wikitext.
There is a cache of the expand() step which persists for the duration
of a single parse operation ($wgParser->mTplExpandCache), but it only
operates on template invocations with no arguments, like {{!}}. It's
possible in theory to cache the expand() results for templates with
arguments, but I didn't do it because it looked like it would be
difficult to efficiently hash the parse tree of the arguments in order
to retrieve the correct entry from the cache. This would be a good
project for future development work.
I think it's fair to constrain parser functions to require that they
return the same result for the same arguments, during a single parse
operation. That's all you need to do to have an effective expand() cache.
However, the benefit would be limited due to the dominance of
infoboxes and navboxes which appear only once in each article. It's
not guaranteed that the result of expand() will be the same when done
at different times or in different articles.
internalParse() takes preprocessed wikitext and produces HTML. The
final output is cached by the parser cache.
-- Tim Starling