#7211 closed bug (wontfix)
trim is 8 times slower on 1.4.3 than 1.4.2 (Chrome 6+)
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | high | Milestone: | 1.5 |
Component: | core | Version: | 1.5 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
The trim function is 8 times slower on 1.4.3 then from 1.4.2.
Here is the test http://jsfiddle.net/SBmaP/
The test is pretty straightforward I wanted to see how fast is native trim against regex trim. The test will run a trim function in a loop and show two alert boxes one for the regex speed and one for the native speed. Under 1.4.3 I get ~1000 and ~500 milliseconds for the regex and the native respectively but in version 1.4.2 (http://jsfiddle.net/SBmaP/1/) the results are ~1000 and ~60 milliseconds which means that trim is about 8 times slower in 1.4.3.
Change History (10)
comment:1 Changed 12 years ago by
Priority: | undecided → low |
---|---|
Status: | new → open |
comment:2 Changed 12 years ago by
In jQuery 1.4.2 it used its own means of trimming whitespace. Now in 1.4.3 it checks to see if the native trim exists and uses that if it does.
It would seem that jQuery's regex trim works quicker than the native trim in some cases. But I think this would depend mainly on the browser AND the size of the word being trimmed. Generally most words would be relatively small.
comment:3 Changed 12 years ago by
Milestone: | 1.4.4 → 1.4.5 |
---|
Retargeting due to severity of regressions in 1.4.3.
comment:4 Changed 12 years ago by
Component: | unfiled → core |
---|---|
Priority: | low → high |
Additionally collecting data here
comment:5 Changed 12 years ago by
The performance test at http://jsperf.com/jquery-trim-vs-string-prototype-trim is not current, trim12 is not the trim that 1.4.2 uses. I have created a new test that shows the bug:
comment:6 Changed 12 years ago by
The perf test based on the test case provided in the ticket. Regardless, the results don't lie on this new perf test.
comment:7 Changed 12 years ago by
Native trim seems the best way forwards.
If and when browser vendors decide to optimize the native trim function, jQuery will get a speed boost for free.
Worrying about the speed of trim in Chrome, seems a bit overkill, when the tests at http://jsperf.com/jq-trim-1-4-2-vs-1-4-3 clearly shows that other browsers benefit a lot from using the native trim
Do we really care if Chrome can do this a few more millions of times per second, versus a 4x boost for iOS?
I think this ticket should be closed without modifying source.
comment:8 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
I think Morgan hit the nail on the head on this one.
comment:9 Changed 12 years ago by
Version: | 1.4.3 → 1.5 |
---|
There wasn't a 1.4.5 release, was actually 1.5.
comment:10 Changed 12 years ago by
Milestone: | 1.4.5 → 1.5 |
---|
There was no 1.4.5 release, was actually 1.5.
Here are multiple results for your test in Chrome (Core 2 Duo 3.06GHz 4096MB)
jQuery 1.4.3:
trim 12: $.trim:
1329 483
932 468
949 467
953 471
945 471
jQuery 1.4.2:
trim 12: $.trim
932 64
1026 75
958 66
1368 81
950 65
While the trim12 results are unsurprisingly roughly the same, the internal $.trim results are quite starkly different.
I should however mention that when you compare this to the FireFox results they do tend to vary. For example, in FireFox the average result with jQuery 1.4.3 was:
trim12 $.trim
2965 1043
and for jQuery 1.4.2
2961 4549
Leaving open in case further test results or comments wish to be contributed.