Tim Starling wrote: I suggest to cache these calls results (as done with "#time"), and to count multiple calls to the same page as one call, in case someone wants to check the same page multiple times. (Title objects are cached anyway, and so are the article IDs, so they don't have to cause multiple queries anyway; they are harder to check, though.) "Then" and "else" should not be cached, just the title and its result.

Rotem Liss wrote: +1 In my little journey in the #ifexist abuse i have found that people use this kind of constructs quite frequently: Lorem ipsum (A ? <strong>: <small>) dolor (A ? </strong>:</small>) sic amet consectetuer adipiscing elit. (A ? "Proin quam. Praesent vulputate libero eu arcu." : "") Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. (A ? "Pellentesque vitae diam." : ) Proin elementum, purus eu rhoncus rhoncus, lacus nisi hendrerit metus, et congue nunc ante vel odio. So it's fixed doing: if (A) { Lorem ipsum <strong>dolor</strong> sic amet consectetuer adipiscing elit. Proin quam. Praesent vulputate libero eu arcu. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Pellentesque vitae diam. Proin elementum, purus eu rhoncus rhoncus, lacus nisi hendrerit metus, et congue nunc ante vel odio. } else { Lorem ipsum <small>dolor</small> sic amet consectetuer adipiscing elit. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Pellentesque vitae diam. Proin elementum, purus eu rhoncus rhoncus, lacus nisi hendrerit metus, et congue nunc ante vel odio. } Which decreases the count incredibly (put that on a template called with different arguments a lot of times from another template used on many pages). So caching the answer for each checked title on the same call will make a difference (and is the sensible thing to do: nobody expects it to return different on the same page, though the double race condition exists). Maybe for clarity split them into '#ifexist count' and 'Active #ifexist count'?

On 12/4/07, Charlotte Webb &lt;charlottethewebb(a)gmail.com&gt; wrote: It seems to include random globs of binary data, like a big chunk of nulls from 0x5004 to 0x54D, another at 0x1100E to 0x117C5, etc. There's over a megabyte of them total in the 13 MB file when I wget it. (Maybe my downloads were corrupted, though.) But you have weirdness like: enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 137 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 1675 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 1775 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 259 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 359 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 475 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 575 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 859 enwiki: http://en.wikipedia.org/wiki/Template:Archive_box 959 which gives nine distinct {{#ifexist:}} counts for the same template -- and 859 total instances of it. The same file with all nulls removed, restricted only to Template:, is under 100 KB. I've uploaded it here: http://twcenter.net/~simetrical/ifexist-truncated.log Of course I'm not sure what to make of some of the duplicates, but either way, things like Template:Archive_box need to be fixed, evidently. And probably a lot of the non-template pages too, that include multiple {{#ifexist:}} templates or that trigger paths not executed on direct view or whatever.

thats how NFS appends work :) -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]

The #ifexist limit has now been reduced to 500 unique calls. A list of broken pages appears at: [[Category:Pages with too many ifexist calls]] or its equivalent localised via pfunc_max_ifexist_category. We're still running on Parser_OldPP, more bugs found. -- Tim Starling