Editing Module talk:Yesno (section)

== Edit request 25 September 2025 ==

{{Edit fully-protected|answered=yes}}

'''Description of suggested change:''' Please merge [[Module:Yesno/sandbox]]. Uses a [[lookup table]] instead of an if-elseif-else statment which is almost 50% as fast as a lookup table as table lookups in Lua are O(1) average case.

I made a benchmark comparing exact current module with the new one: [[Module:Sandbox/Waddie96]]. To run, [https://en.wikipedia.org/w/index.php?title=Module:Sandbox/Waddie96&action=edit go into edit mode], in the LuaConsole type <code>'''<span style="color:darkblue;">=p.main()</span>'''</code>. Output compares the two with 500,000 iterations. My output showed almost 30–50% speed improvement which is a lot for a module transcluded [https://en.wikipedia.org/wiki/Special:WhatLinksHere/Module:Yesno on 31,723,438 pages].

<code style="display:block;" class="mw-code mw-highlight mw-highlight-lang-bash pre">'''<span style="color:darkblue;">=p.main()</span>'''
Running benchmarks with <span style="color:var(--color-subtle);">500000</span> iterations...
Lookup table took <span style="color:maroon;">3.6897</span> seconds for <span style="color:var(--color-subtle);">8500000</span> operations 
If-elseif chain took <span style="color:maroon;">5.0883</span> seconds for <span style="color:var(--color-subtle);">8500000</span> operations
</code>
'''Diff:''' [https://en.wikipedia.org/w/index.php?title=Module%3AYesno%2Fsandbox&diff=1313227532&oldid=1313226214 Diff here].


<span class="fn nickname" style="color:#CD0000">[[User:Waddie96|waddie96]] ★ ([[User talk:Waddie96|talk]])</span> 01:36, 25 September 2025 (UTC)
: So you're saving about 165 nanoseconds per call, and it's unlikely this is getting called so many thousands of times that that really adds up? That's not terribly convincing. OTOH, other than oddly assigning <code>TO_NUMBER = tonumber</code> and <code>TYPE = type</code> without any explanation, it seems like an ok increase in clarity to have almost all the accepted values together at the top. You might go a little further and stick boolean true and false into <code>BOOLEAN_MAP</code> and skip checking types at all, as Lua doesn't do any type conversion on table keys and allows anything except nil and NaN. [[User:Anomie|Anomie]][[User talk:Anomie|⚔]] 01:58, 25 September 2025 (UTC)
:: [[WP:PERF]]. Probably the amount of time it would take for the parser to reparse almost every page on the project triggered by this edit would greatly exceed the time saved for the forseeable future. And the code as is seems plenty clear enough, so I'm not seeing the clarity argument either. I'm contesting this request. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 02:25, 25 September 2025 (UTC)
:::This benchmark case isn't perfectly representitive. Generally, the average template call or invoke from a page will use Yesno just a few times, repeated among a bunch of different template calls. That means, if a singular call ends up using YesNo ~5 times or less in total, the lookup table version technically has ''more'' overhead than the current simplistic implementation (upwards of ~2x slower, though that means little at this scale), due to the time it takes to create the lookup table and localise the globals every time. Also, as mentioned above, this is fighting to save milliseconds (if even that much) in the wrong place - it definitely won't be fixing any multi-second or 10s timeout pages, which is where optimisations matter. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 08:19, 25 September 2025 (UTC)
::::Yes, you make an excellent point, so lets break it down: '''The economics of optimization at scale:'''
::::Saving time or indefinite use of the slower iteration?
::::[[Module:Yesno/sandbox]] refactored to use a lookup table <code>(BOOLEAN_MAP) → O(1)</code>, instead of nested if-elseif-else statements. This reduces the number of operations per call from ~7 to ~2.
::::If speedup per call is ~70%, you only need a few pageviews per page to amortize the reparse.
::::'''Impact on Wikimedia at scale:'''
::::* Pages affected: ~32 million transclusions
::::* Estimated calls per year: ~32 billion
::::* Aggregate operations saved: ~160 billion operations/year
::::* Speedup per call: 71%
::::* Even if we consider just one pageview per page, the benefit already exceeds the cost.
::::'''Ongoing benefit:'''
::::That doesn't only affect the next child down that uses this module, but:
::::* Every single page view that uses this module gets the speedup
::::* Every edit that triggers reparsing gets the speedup
::::* Every template expansion gets the speedup
::::'''Savings (rough estimates):'''
::::* '''Time saved per CPU:''' ~80 seconds/year (per CPU handling pageviews)
::::* '''Real-world effect:''' reduced CPU load, faster page loads for millions of pageviews
::::'''Break-even on one-time reparse cost:'''
::::* Only '''2–3 pageviews per transcluded page''' are required to offset the one-time parsing cost
::::* For Wikimedia’s scale (~4,500 views/second), the break-even is achieved in '''~3 hours''' for the first affected pages{{efn|Each page using the yesno module only needs to be viewed/edited 2-3 times after the optimization to break even. Approx. 1 day = 391 million views. ~= ''3 hours'' for 3 pageviews to break even on the reparse cost. As currently enwiki receives ~4,500 views per second. Estimate: 69 million edits and 143 billion page views in the previous year divided by (86,400 sec/day * 365 days).[https://stats.wikimedia.org/#/en.wikipedia.org/reading/total-page-views/normal|bar|1-year|~total|monthly] 12 billion page views just in Aug-Sept 2025 see [https://stats.wikimedia.org/#/en.wikipedia.org WikiStats].}}
::::'''Technical benefits:'''
::::* O(1) lookup vs O(n) linear search
::::* Function caching avoids repeated global access overhead
::::* Cleaner, more maintainable code
::::* Adding new values now only requires updating the lookup table
::::This optimization demonstrates how small changes in module logic can lead to aggregate performance improvements.
:::: <span class="fn nickname" style="color:#CD0000">[[User:Waddie96|waddie96]] ★ ([[User talk:Waddie96|talk]])</span> 05:44, 27 September 2025 (UTC)
::::@[[User:Aidan9382|Aidan9382]] I'm happy to fix those latter cases too going forward, point me in the right direction 😄 <span class="fn nickname" style="color:#CD0000">[[User:Waddie96|waddie96]] ★ ([[User talk:Waddie96|talk]])</span> 05:46, 27 September 2025 (UTC)
:::::Some comments:
:::::* The point is that there is no way to "fix" this, because nothing's broken. At the end of the day, you are trying to optimise 14 equality checks. Infact, the time it takes to require this module ''after it's been cached'' is longer than an average-case use of the if-else chain function. Even if this would technically improve the performance to the degree of nanoseconds on a bunch of pages (which isn't guaranteed per below), that is the wrong place to be looking for optimisations as a wikipedia editor. The focus should be on pages that spend a significant amount of time (upwards of multiple seconds) on lua evaluation, since that's when it can start to disrupt editing and reading, which is what we care about.
:::::* {{tq|Speedup per call: 71%}} is ''best case'' scenario, and as I've described above, is not always the case. Let's say you have a page that has <code><nowiki>{{T1|param=yes}}{{T2|param=no}}</nowiki></code> on it, and that each of these template calls eventually call into this module to check the value of <code>param</code>. Since both will create seperate lua states, both have to complete the initial uncached require on this module. That time increases significantly when adding a table creation, to the point where this specific setup would have Yesno spending ~2x more time executing than the current version.
:::::* The idea of {{tq|Every single page view that uses this module gets the speedup}} is incorrect - the evaluated state of pages are cached, and the majority of views will not cause a reevaluation, so the scale that you suggest this improvement is running at isn't accurate. Also, {{tq|Every template expansion gets the speedup}} is essentially the prior two points reiterated.
:::::[[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 12:21, 27 September 2025 (UTC)

{{notelist-talk}}