Bug Tracker

Ticket #7211 (closed bug: wontfix)

Opened 4 years ago

Last modified 3 years ago

trim is 8 times slower on 1.4.3 than 1.4.2 (Chrome 6+)

Reported by: erlichmen@… Owned by:
Priority: high Milestone: 1.5
Component: core Version: 1.5
Keywords: Cc:
Blocking: Blocked by:

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

comment:1 Changed 4 years ago by addyosmani

  • Priority changed from undecided to low
  • Status changed from new to open

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.

Last edited 4 years ago by addyosmani (previous) (diff)

comment:2 Changed 4 years ago by tomgrohl

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.

Last edited 4 years ago by tomgrohl (previous) (diff)

comment:3 Changed 4 years ago by snover

  • Milestone changed from 1.4.4 to 1.4.5

Retargeting due to severity of regressions in 1.4.3.

comment:4 Changed 4 years ago by rwaldron

  • Priority changed from low to high
  • Component changed from unfiled to core

comment:5 Changed 4 years ago by anonymous

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:

 http://jsperf.com/jq-trim-1-4-2-vs-1-4-3

comment:6 Changed 4 years ago by rwaldron

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 4 years ago by Morgan Roderick <morgan@…>

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 4 years ago by snover

  • Status changed from open to closed
  • Resolution set to wontfix

I think Morgan hit the nail on the head on this one.

comment:9 Changed 4 years ago by john

  • Version changed from 1.4.3 to 1.5

There wasn't a 1.4.5 release, was actually 1.5.

comment:10 Changed 4 years ago by john

  • Milestone changed from 1.4.5 to 1.5

There was no 1.4.5 release, was actually 1.5.

Note: See TracTickets for help on using tickets.