Revisiting this now that I've looked a bit more into it: careful use of #varexists
can save a significant amount on the NewPP parser report metrics (in particular "Preprocessor visited node count", "Post-expand include size", and "Template argument size"), over my go-to {{ #if: {{ #var:
construction.
For example, this version of "Template:Chapter" on my wiki (the current version as of writing this, but it won't be for long), as used on the current version of the page "Dark Yugi (manga)" (where the template is transcluded 338 times), results in the following NewPP report:
NewPP limit report
Cached time: 20210907163321
Cache expiry: 1209600
Dynamic content: false
[SMW] In‐text annotation parser time: 0.017 seconds
CPU time usage: 4.748 seconds
Real time usage: 8.358 seconds
Preprocessor visited node count: 64228/1000000
Preprocessor generated node count: 60933/1000000
Post‐expand include size: 418313/2097152 bytes
Template argument size: 35083/2097152 bytes
Highest expansion depth: 17/40
Expensive parser function count: 0/100
Unstrip recursion depth: 1/20
Unstrip post‐expand size: 112756/5000000 bytes
Lua time usage: 2.450/20.000 seconds
Lua virtual size: 14.27 MB/50 MB
Lua estimated memory usage: 0 bytes
However, changing the first line in the template:
<includeonly>{{ #vardefine: $smw | {{ #var: $smw | {{ #if: {{ #show: }} | off | on }} }}<!-- standard implementation -->
to
<includeonly>{{ #varexists: $smw || {{ #vardefine: $smw | {{ #if: {{ #show: }} || 1 }} }}<!-- standard implementation -->
and line 40 from
}}{{ #vardefine: $chapter-name | {{ #ifeq: {{ #var: $chapter-mode }} | number || {{ #ifeq: {{ #var: $smw }} | on | {{ #show: {{ #var: $chapter-pagename }} |?English name }} }} }}
to
}}{{ #vardefine: $chapter-name | {{ #ifeq: {{ #var: $chapter-mode }} | number || {{ #if: {{ #var: $smw }} | {{ #show: {{ #var: $chapter-pagename }} |?English name }} }} }}
...results in the following report:
NewPP limit report
Cached time: 20210907165826
Cache expiry: 1209600
Dynamic content: false
[SMW] In‐text annotation parser time: 0.015 seconds
CPU time usage: 4.776 seconds
Real time usage: 8.623 seconds
Preprocessor visited node count: 63678/1000000
Preprocessor generated node count: 60933/1000000
Post‐expand include size: 417637/2097152 bytes
Template argument size: 35083/2097152 bytes
Highest expansion depth: 17/40
Expensive parser function count: 0/100
Unstrip recursion depth: 1/20
Unstrip post‐expand size: 112756/5000000 bytes
Lua time usage: 2.570/20.000 seconds
Lua virtual size: 14.3 MB/50 MB
Lua estimated memory usage: 0 bytes
Note in particular that "Preprocessor visited node count" dropped from 64228 to 63678, and "Post-expand include size" dropped from 418313 to 417637.
However, as things stand, I am unable to use this method in more places in "Template:Chapter", since other variables I'd like to use it on are always defined, and communicate meaningful state if they are empty (there is no way around this, since subsequent transclusions may store nonempty values to these variables, and then empty values again, and so on). For example, changing line 28 from
}}{{ #vardefine: $chapter-subseries | {{ #if: {{ #var: $chapter-series }}
to
}}{{ #vardefine: $chapter-subseries | {{ #varexists: $chapter-series
...would result in "Preprocessor visited node count" dropping further to 60641, and "Post-expand include size" dropping to 371846, but would not work correctly in some cases of multiple transclusions of the template on the same page, as explained above. However, you don't even need to look past $smw
to find suboptimal behavior: because it can be defined but empty, it must be tested on line 40 via {{ #if: {{ #var: $smw }} ...
, instead of being able to just use {{ #varexists: $smw ...
!
This could be fixed in one of two ways: add a function to undefine a variable entirely, or add a way to test for variable existence that considers empty-but-defined variables to not exist (whether by a modification of #varexists
, or the introduction of a new parser function).
(I am, of course, aware of Scribunto and Lua - and we do use modules for a number of things on the wiki already - but we currently only have one editor who is able and willing to develop and maintain modules for us, and they don't have much time to spend on the wiki; I've tried learning myself, but could never get the hang of it.)