Module talk:String

The wiki supports parser functions like 4 and 1 . Why add this? if there's a reason, should we retrofit existing uses of the parser functions? - Harakoni (Wiki Moderator) (talk) 22:01, 8 August 2024 (UTC)

I probably should have put this on a test page first. The main reason was that earlier testing suggested this to be faster than the parser functions. Because I wanted to be sure, I imported this module to test function by function. Unfortunately, I lack the time to do it in on 1 go. What I have tested since then:

{{#len:string}} is faster than {{#invoke:String|len|target_string}}

{{#pos:string|search term|offset}} is faster than {{#invoke:String|find|source_string|target_string|start_index|plain_flag}}.

String|find always gives #pos:string +1

{{#sub:string|start|length}} is faster than {{#invoke:String|sub|target_string|start_index|end_index}}

The index are of by 1. Again.

{{#count:string|substring}} is faster than {{#invoke:String|count|source_str|pattern_string|plain_flag}}

String|count does accept Ustring patterns, but I'm uncertain of benefit. Misread this. There is no upside here.

{{#invoke:String|join|separator|string1|string2|...}} has no equivalent. Unsure of use case.

{{#replace:string|search term|replacement term}} is faster than {{#invoke:String|replace|source_str|pattern_string|replace_string|replacement_count|plain_flag}}

String|replace has additional options.

String|escapePattern seems to have no equivalent. Maybe #urlencode, but that doesn't work here. Limited utility.

String|rep seems to have no equivalent.

String|endswith is maybe equivalent to {{#if:{{#sub:string|start|length}}|yes}}. That would make endswith (marginally) faster.

EDIT: A better fit is #pos within an #if: {{#if:{{#pos:string|search}}|yes}}. That would make it equal and less versatile.

string|match seems to have no equivalent. REGEX is not something I'm good with, so I can't evaluate it right now.

All in all, it seems several parts of thus module have worse performance. The REGEX option may be useful, but I can barely read it. I did not try a scaling test.

Regular expressions and REGEX are not remotely the same, even if superficially similar.

--Arcangelus (talk)

Some more testing done.

Removing the following functions due to redundancy:

• String|len (strictly worse than #len)
• String|sub (Slower than #sub)
• String|endswith (Equal to #pos within an #if)

The following overlap with parser functions, but accepts REGEX:

• String|find (Slower than #pos).
• String|replace (Slower than #replace).
• String|count (Slower than #count).

• Faster than #count if searching for 3+ letters (due to the added #expr required to get the same number)

• string|match overlaps with #sub, but geared for REGEX more than anything else.

The following have no parser function equivalent:

• String|escapePattern. May delete for lack of purpose.
• String|rep. May delete for lack of purpose.
• String|join. May delete for lack of purpose.
• String|pos. Unsure. This is the opposite of #pos, so while it may have purpose it can also be confusing.

--Arcangelus (talk) 16:59, 9 August 2024 (UTC)

I'm kinda surprised that the parser functions work faster than the Lua option. Lua only seems worth it to wholly replace medium to heavy templates rather that piecemeal functions. For instance, replacing #explode with split is a bust, but replacing a larger section of a template that happens to use explode repeatedly with a customized function may be worth it. It may also be worth it for "easier to read" reasons. I suspect the crux of the issue is the cost of the #invoke command itself.---Arcangelus (talk) 14:28, 6 September 2024 (UTC)