Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
strtr()
is slow, compared to str_replace()
UrlGenerator::doGenerate()
uses it for no actual reason.
Proposed resolution
Use str_replace()
Remaining tasks
User interface changes
API changes
Data model changes
Beta phase evaluation
Issue category | Task because nothing is broken. |
---|---|
Issue priority | Normal, because just a little micro-optimization, but micro-optimizations can also add up. |
Prioritized changes | The main goal of this issue is performance. |
Disruption | Not disruptive for core/contributed and custom modules/themes. |
Comment | File | Size | Author |
---|---|---|---|
#12 | interdiff.txt | 1.87 KB | dawehner |
#12 | 2538982-12.patch | 1.66 KB | dawehner |
#7 | increment.txt | 1.67 KB | pwolanin |
#7 | 2538982-7.patch | 1.62 KB | pwolanin |
| |||
#2 | 2538982-2.patch | 1.47 KB | dawehner |
Comments
Comment #1
dawehnerDiff%
Diff
(microsec)
Diff%
MemUse
Diff
(bytes)
Diff%
PeakMemUse
Diff
(bytes)
Diff%
Comment #2
dawehnerGood catch fabianx!
Comment #4
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedMicro-optimization, but it is well known that str_replace is faster than strtr, so lets do that.
Comment #5
Wim LeersShould we also file an upstream issue?
Comment #6
Wim LeersThis is difficult to parse.
Can we put these on separate lines, to remove the visual suggestion that this is a key-value map?
Comment #7
pwolanin CreditAttribution: pwolanin as a volunteer commentedMaybe better to use a list() construct here? I think it's clearer to read.
Comment #8
dawehnerSure, why not.
Comment #9
Wim LeersRTBC+1
Comment #10
alexpottSo what's actually faster... if we're doing a micro-optimisation adding an extra operation seem interesting.
Comment #11
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commented#10:
(http://php.net/manual/en/function.list.php)
So this should be identical to using:
However I benchmarked the cases and this is the result:
with the following scenarios (xhprof off):
So yes, list() is slightly slower than directly using decodedChars[0] and decodedChars[1], but is the same when using temporary variables.
Obviously the single case is fasted, but any optimization is likely not worth the additional complexity of the isset(), etc. and part of that is also saving one array traversal.
So it is probably just the 5x improvement over str_tr that really matters here - unless we never have a use-case to support more than one encoded character.
Comment #12
dawehnerThank you fabian! Good to learn that.
Given with that we support both cases I would suggest to go with that, just to add it to the documentation that you can also use arrays. It is quite an edge case to override it though.
Comment #13
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedOh, that is a very sweet solution :).
Comment #14
alexpottThanks everyone! Committed 3555e2b and pushed to 8.0.x. Thanks!
Thank you for adding the beta evaluation to the issue summary.
Comment #16
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commented