Difference between revisions of "Module talk:String"
Jump to navigation
Jump to search
(Created page with "The wiki supports parser functions like {{#len: fish}} and {{#pos:sandwich|a}} . Why add this? if there's a reason, should we retrofit existing uses of the parser functions?...") |
Arcangelus (talk | contribs) |
||
Line 1: | Line 1: | ||
The wiki supports parser functions like {{#len: fish}} and {{#pos:sandwich|a}} | The wiki supports parser functions like {{#len: fish}} and {{#pos:sandwich|a}} | ||
. Why add this? if there's a reason, should we retrofit existing uses of the parser functions? - [[User:Harakoni|Harakoni (Wiki Moderator)]] ([[User talk:Harakoni|talk]]) 22:01, 8 August 2024 (UTC) | . Why add this? if there's a reason, should we retrofit existing uses of the parser functions? - [[User:Harakoni|Harakoni (Wiki Moderator)]] ([[User talk:Harakoni|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: | ||
+ | ::<nowiki>{{#len:string}}</nowiki> is faster than <nowiki>{{#invoke:String|len|target_string}}</nowiki> | ||
+ | ::<nowiki>{{#pos:string|search term|offset}}</nowiki> is faster than <nowiki>{{#invoke:String|find|source_string|target_string|start_index|plain_flag}}</nowiki>. | ||
+ | :::'''String|find''' always gives #pos:string +1 | ||
+ | ::<nowiki>{{#sub:string|start|length}}</nowiki> is faster than <nowiki>{{#invoke:String|sub|target_string|start_index|end_index}}</nowiki> | ||
+ | :::The index are of by 1. Again. | ||
+ | ::<nowiki>{{#count:string|substring}}</nowiki> is faster than <nowiki>{{#invoke:String|count|source_str|pattern_string|plain_flag}}</nowiki> | ||
+ | :::'''String|count''' does accept Ustring patterns, but I'm uncertain of benefit. | ||
+ | ::<nowiki>{{#invoke:String|join|separator|string1|string2|...}}</nowiki> has no equivalent. Unsure of use case. | ||
+ | ::<nowiki>{{#replace:string|search term|replacement term}}</nowiki> is faster than <nowiki>{{#invoke:String|replace|source_str|pattern_string|replace_string|replacement_count|plain_flag}}</nowiki> | ||
+ | :::'''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 faster (barely). | ||
+ | ::'''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.[[User:Arcangelus|Arcangelus]] ([[User talk:Arcangelus|talk]]) |
Revision as of 03:33, 9 August 2024
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.
- {{#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 yes. That would make endswith faster (barely).
- 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.Arcangelus (talk)