J
J
Jorge
G
Gregor Kofler
Jorge meinte:
Can't help - I always have to think of Bela Lugosi [1]...
Gregor
[1]
Can't help - I always have to think of Bela Lugosi [1]...
Gregor
[1]
J
Jorge
Bevare, Bevaaare :
How to speed up (up to 3x !) global object's method calls [for
example, Math.method()]: by aliasing them in a local var:
<http://jorgechamorro.com/cljs/033/>
G
Gabriel Gilini
Chrome 1.0.154.43 on Windows NT
Test Ops/sec
full local aliasing 676170
full "global" aliasing 679676
partial local aliasing 696285
partial "global" aliasing 693338
no aliasing 700752
P
Peter Michaux
Firefox 3.0.5 on Intel Mac OS X 10.5
Test Ops/sec
Ready
full local aliasing 235197
full "global" aliasing 161481
partial local aliasing 181518
partial "global" aliasing 140683
no aliasing 94672
-------------------
Safari 3.2 on Intel Mac OS X 10_5_5
Test Ops/sec
full local aliasing 377306
full "global" aliasing 256909
partial local aliasing 234481
partial "global" aliasing 184976
no aliasing 143375
P
Peter Michaux
There goes the idea that accessing globals is universally slower.
Peter
J
Jorge
Yes.
Aliasing into a local var will still speed it up in ~ all the browsers
(most notably, IE), and slow it down (only very slightly) in Chrome
(AFAICT).
G
Gregor Kofler
Peter Michaux meinte:
Slowest case roughly 50% slower than fastest.
In comparison:
Safari 528.5+) on Linux x86_64 (i.e. Midori on WebKit)
Test Ops/sec
full local aliasing 485855
full "global" aliasing 434335
partial local aliasing 431476
partial "global" aliasing 405826
no aliasing 408864
The slowest case is approx 16% slower than the fastest.
Bottom line, I wouldn't put an *extra* effort into achieving full local
aliasing.
JFTR:
Firefox 2.0.0 on Linux x86_64 (hey ho it's Opera 9.63 - so much for
"Browser Sniffing"...
Test Ops/sec
full local aliasing 234798
full "global" aliasing 144890
partial local aliasing 164863
partial "global" aliasing 173966
no aliasing 130467
Gregor
Slowest case roughly 50% slower than fastest.
In comparison:
Safari 528.5+) on Linux x86_64 (i.e. Midori on WebKit)
Test Ops/sec
full local aliasing 485855
full "global" aliasing 434335
partial local aliasing 431476
partial "global" aliasing 405826
no aliasing 408864
The slowest case is approx 16% slower than the fastest.
Bottom line, I wouldn't put an *extra* effort into achieving full local
aliasing.
JFTR:
Firefox 2.0.0 on Linux x86_64 (hey ho it's Opera 9.63 - so much for
"Browser Sniffing"...
Test Ops/sec
full local aliasing 234798
full "global" aliasing 144890
partial local aliasing 164863
partial "global" aliasing 173966
no aliasing 130467
Gregor
J
Jorge
But see what happens in the iPhone:
Safari 3.1.1 on iPhone OS 2.2
Test Ops/sec
full local aliasing 12780
full "global" aliasing 7287
partial local aliasing 7601
partial "global" aliasing 5604
no aliasing 3738
3.4x !
G
Gregor Kofler
Jorge meinte:
Agreed (that's why I stressed the "extra"). And it also devalues the
"nowadays browsers are fast enough for library x" argument.
Gregor
But see what happens in the iPhone:
Safari 3.1.1 on iPhone OS 2.2
Test Ops/sec
full local aliasing 12780
full "global" aliasing 7287
partial local aliasing 7601
partial "global" aliasing 5604
no aliasing 3738
3.4x !
Agreed (that's why I stressed the "extra"). And it also devalues the
"nowadays browsers are fast enough for library x" argument.
Gregor
J
Jorge
Well, it's good to know (just in case) about this aliasing business,
but, still, it doesn't matter very much if all a script takes to
execute is (usually) 0.1s or 0.34s, isn't it ? There's quite a lot of
truth (nowadays, but not necessarily in the future) in this: "if
JavaScript were infinitely fast, most web applications would run at
about the same speed":
<http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=872]
Don't you think so ?
But I can't wait to apply the trick here <http://jorgechamorro.com/
jcb.html> to see what really happens.
P
Peter Michaux
If JavaScript was infinitely fast, I would definitely abstract it with
another language with tail call elimination. As it stands, JavaScript
is not fast enough.
Peter
J
Jorge
IIRC, Gregor's got an Opera that's infinitely fast. It's so amazing.
G
Gregor Kofler
Jorge meinte:
Yepp, that was incredible. Unfortunately I can't recreate this behaviour
on the new machine. Perhaps some sort of overrun, since Opera should be
now twice infintely fast.
Gregor
Yepp, that was incredible. Unfortunately I can't recreate this behaviour
on the new machine. Perhaps some sort of overrun, since Opera should be
now twice infintely fast.
Gregor
J
jorge
Jorge said:
A video explaining this very same thing (among others):
"Speed Up Your JavaScript"
by Nicholas C. Zakas:
L
Lasse Reichstein Nielsen
[email protected] said:
The "up to 3x" part might require a particularly braindead browser
I just ran the benchmark in Opera and Chrome, and while there is a
difference, it's closer to 10% at the most.
Mr. Zakas does have some points, but not all of them hold up in an
optimized engine, and none of them apply all the time (if it's not in
a loop, don't bother optimizing). Taking all he says as gospel will
lead to a lot of premature optimization.
/L
J
Jorge
[email protected] said:
The "up to 3x" part might require a particularly braindead browser
I just ran the benchmark in Opera and Chrome, and while there is a
difference, it's closer to 10% at the most.
[[ The link to test var access speed was http://jorgechamorro.com/cljs/032/
not /033/. ]]
But as the browsers lately are being upgraded/updated/optimized so
often, almost monthly, so, for example, Safari 3.21/Mac (squirrelFish)
was 6.3x faster fetching a local than a global var. but Safari 4.0/Mac
(NITRO) -final version as of today- is equally fast no matter where in
the scope chain the var comes from. ~the same (the same as 3.21, not
the same as 4.0) goes for Opera 9.64/Mac. But FF 3.0.10/Mac isn't
optimized yet: locals are fetched 258x faster than globals (to be
fair, in this test, globals are quite far away in terms of scope chain
length), and every step further along the scope chain is quite
expensive (FireBug disabled), see :
Firefox 3.0.10 on Intel Mac OS X 10.5
Test Ops/sec
globalVar 31778
globalVar as window.globalVar 31679
globalVar as localVar.globalVar 47575
globalVar as this.globalVar 47575
localVar 8193536
closureVarFirstLevel 401234
closureVar2ndLevel 148159
closureVar3rdLevel 85967
closureVar4thLevel 64205
closureVar5thLevel 51785
closureVar6thLevel 43484
closureVar7thLevel 36803
parameters 6132884
Yes, I agree. I was thinking exactly the same. And I believe that the
reflow business (the last part of the video) is not exactly as he puts
it... I don't think one needs to be so paranoid about touching the
DOM, because, the way I see it, redraws take place (at least up until
now) at well-known times.
With regard to live collections, I couldn't agree more.