On 11-04-08 02:37 PM, Brion Vibber wrote: I could swear we locally cache template wikitext, and save preprocessed data to the object cache. Least I think thats what I gathered last time I read the code. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Daniel Friesen wrote: 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). On the original question: The tree will be reused, but it has to be expanded again. It's not clear that you gain by using a library since you will pay the library costs on all articles using it. Templates should be kept simple (yes, enwiki is particularly bad at that). In early 2007, eswiki implemented a library template (Plantilla:Interproyecto) which was used for adding any interwikis to sister projects. It caused server problems and got disabled by the sysadmins.

Roan Kattouw wrote: 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?

On 11/04/11 06:32, Platonides wrote: 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

2011/4/11 Daniel Friesen <lists(a)nadir-seen-fire.com> Simply, {{Foo/{{{1}}}|...}} links to different pages, while {{Foo|{{{1}}}|...}} points to the same page. I had been frustrated when I tried to use Labeled Section Transclusion to build template libraries :-), that would be an excellent way to build "collection of objects" into a wiki page, both of "methods" and "attributes"... ... but #lst doesn't parse raw wiki code "from scratch". If it would (t.i.: if #lst would read wiki code "as it is", before any parsing of it, ignoring at all the code outside labelled section: t.i. ignoring noinclude, html comment tags... anything) interesting scenarios would raise. But, if there's no performance gain with {{Foo|{{{1}}}|...}} trick, I'll use {{Foo/{{{1}}}|...}} for sure. KISS is always a good guide line. :-) Alex

2011/4/11 Daniel Friesen <lists(a)nadir-seen-fire.com> Are you a wikisource contributor? If you are, I guess that you considered too this syntax, pointing to what I wrote into my last message: {{#section:Foo|{{{1}}}}} but... it refuses to run, if section {{{1}}} of page Foo is a "method" (while its runs obviuosly if section is an "attribute"). :-) Alex

On Mon, Apr 11, 2011 at 5:59 AM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote: Yes, I implemented this with Tim's help to try to cut down on the CPU load caused by lots of Cite templates, IIRC. If I recall correctly, the performance benefit was not particularly substantial. -- Andrew Garrett http://werdn.us/