Linked by Thom Holwerda on Thu 13th Sep 2012 20:00 UTC, submitted by MOS6510
Mozilla & Gecko clones "Over the past year and a half I've been spending more and more of my time working with Mozilla's latest project, Firefox OS. During that time I've fallen in love with the project and what it stands for, in ways that I've never experienced with a technology platform before." I'm not convinced just yet. I hope it succeeds, but I just doubt it actually will.
Thread beginning with comment 535235
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Another fallen mobile OS.
by Alfman on Sat 15th Sep 2012 17:18 UTC in reply to "RE[6]: Another fallen mobile OS."
Alfman
Member since:
2011-01-28

galvanash,

"I was simply pointing out that it isn't purely because of object access. Object access is slower of course, but the bulk of the time is actually spent on engine level stuff (like memory allocation)."

If I understood you correctly, you may be suggesting that JS only spent ~20ms (we're handwaiving here) doing actual work and the rest was language support overhead. That's a peculiar thing to say, but I guess that's plausible. However I don't see why it changes anything because the overhead is still there regardless of what you attribute it to. Hopefully there is room for improvement.


"That is my point though - only about 40% of that overhead you measured is due to object access. I removed it and the code runs 2x as fast, but it is still more than 50x slower than GCC. The big difference is memory allocation and general engine overhead."

Well, just for kicks I've rerun my original code but with a new timer around the inner loop.

entire script=3.032
inner loop = 3.027

So I think we can rule out memory allocation overhead as a culprit (Unless javascript is continuously reallocating memory unnecessarily in the inner loop?). Still impressive compared to JS engines from a few years go, but I think further optimisation is going to be increasingly difficult.


"Like I said, that isn't a fixed cost - it is highly dependent on the code. But it does tend to become less and less significant the larger and more complex the code base becomes."

You know I can't let you get away with a statement like that without some kind of evidence ;)

Edited 2012-09-15 17:21 UTC

Reply Parent Score: 2

galvanash Member since:
2006-01-25

Well... I withdraw most of what I posted...

It turns out Chrome's profiler does some very weird shit when you are profiling naked code in the global scope. I rewrote the code so that it is contained in a function, so that all the variables are local.

The timing didn't really change, but what changed was where Chrome was reporting % of time spent...

Long story short - Array access is faster than Object access, but either way that is where the majority of time is being spent in your test code.

Hell - I don't know exactly what Chrome was reporting before when it was showing 10-15ms... It ends up reporting things completely differently once you get out of the global scope. I just assumed it was reporting things correctly... sorry about that.

If you instead did something focusing on the calculations involved and less on the object access (obviously this wont give the same result)...


function dostuff() {
var i=9999;
var coords=new Array(i+1);
var ci,cj;

console.profile();
while(--i) {
coords[ i ] = (i + i) / 2;
coords[ i ] = (coords[ i ] + i) / 2;
coords[ i ] = (coords[ i ] + i) / 2;
}
console.profileEnd();
}


You end up with this taking only about 6ms on my machine... Same operations same number of times - just no object access and a simpler loop with just one control variable.

So all in all I would say your original observation was dead on - most of the delta between GCC and JS in your example is purely object access.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

galvanash,

"So all in all I would say your original observation was dead on - most of the delta between GCC and JS in your example is purely object access."

The question becomes how to optimise it. I think you may have been on the way to this idea before getting sidetracked by my benchmark: in theory the JS compiler might convert the dynamic object into a static structure under the hood. But I see that as being a difficult challenge because in JS we don't know which members to allocate prior to execution. A simple analysis may work for simple scripts, but I can conceive of other cases where the compiler will have to run the entire script before being able to determine what static structure it should be using.

We probably ought to revisit this topic on a new article with more time to discuss it.

Edited 2012-09-17 01:28 UTC

Reply Parent Score: 2