Editing Module talk:Sidebar (section)

== Proposed performance optimization: Replacing remaining mw.ustring functions with native string library ==

Hi everyone,

While reviewing the module's code, I noticed that an excellent performance optimization was previously implemented in the 'move_hiding_templatestyles' function by switching from 'mw.ustring' to the native Lua 'string.gmatch' and 'string.gsub' functions. 

However, several other functions in this module are still heavily relying on 'mw.ustring' for processing text patterns that are strictly ASCII (such as internal configuration patterns, HTML/CSS class names, and argument keys). Since 'mw.ustring' adds overhead by routing requests through PHP, replacing it with the native 'string' library where multibyte character support isn't needed will yield better CPU efficiency given the high volume of transclusions this module handles.

I propose updating the following functions to use native Lua string methods:

* 'categorizeTemplatesWithInlineStyles': Change 'mw.ustring' to 'string.find'. (line #23)
* 'trimAndAddAutomaticNewline': Change 'mw.ustring.gsub' and 'mw.ustring.find' to 'string.gsub' and 'string.find'. (lines #36 and #37)
* 'detectChild': Change 'mw.ustring.find' to 'string.find'.  (line #48)
* 'has_list_class': Change both instances of 'mw.ustring.find' to 'string.find'. (lines #74 and #76)

Since the template parameters and basic syntax checkers ('^[#*:;]', '^{|', 'class', etc.) strictly look for basic ASCII characters, this is a completely safe drop-in optimization. 

I would appreciate it if an editor or interface administrator could look into this. We can implement and thoroughly test these changes in the module's sandbox first to ensure everything works flawlessly before patching the live module. Let me know what you think!

[[User:GKNishimoto|GKNishimoto]] ([[User talk:GKNishimoto|talk]]) 01:39, 29 May 2026 (UTC)

:'''Update:''' After reflecting further on this and reviewing the cross-wiki ecosystem, I realize there is a broader architectural layer to consider here.
:While switching to the native <code>string</code> library would give us a clear performance boost in terms of CPU efficiency on enwiki, keeping <code>mw.ustring</code> in these specific functions might very well be an intentional design choice for '''cross-wiki compatibility'''. Since enwiki acts as the upstream source for many other language Wikipedias, modules are frequently imported into wikis that utilize multibyte UTF-8 characters for argument keys, custom CSS classes, or specific page titles.
:In this sense, preserving <code>mw.ustring</code> works as a safeguard to ensure the module doesn't break upon export, even if it introduces a small overhead for strictly ASCII environments like ours.
:I still believe it's worth evaluating if we can safely optimize certain strictly core-syntax functions (such as the wikitext list syntax checkers in <code>trimAndAddAutomaticNewline</code>), but I completely understand if the consensus is to prioritize global portability and robust internationalization over micro-optimizations. I'd love to hear the interface administrators' thoughts on where we should draw the line between performance and cross-wiki safety here.
:[[User:GKNishimoto|GKNishimoto]] ([[User talk:GKNishimoto|talk]]) 11:34, 29 May 2026 (UTC)