Roan Kattouw wrote: >> One easy hack to reduce this problem is just to only provide a few >> options for stub threshold, as we do with thumbnail size. Although >> this is only useful if we cache pages with nonzero stub threshold . . >> . why don't we do that? Too much fragmentation due to the excessive >> range of options? > Maybe; but the fact that the field is present but set to 0 in the > parser cache key is very weird. SVN blame should probably be able to > tell who did this and hopefully why. > > Roan Kattouw (Catrope)
Look at Article::getParserOutput() on how $wgUser->getOption( 'stubthreshold' ) is explicitely check that it is 0 before enabling the parser cache. *There are several other entry points to the ParserCache in Article, it's a bit mixed. Note that we do offer several options, not only the free-text field. I think that the underlying problem is that when changing an article from 98 bytes to 102, we would need to invalidate all pages linking to it for stubthresholds of 100 bytes. Since the pages are reparsed, custom values are not a problem now. I think that to cache for the stubthresholds, we would need to cache just before the replaceLinkHolders() and perform the replacement at the user request. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
