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 535040
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Another fallen mobile OS.
by galvanash on Fri 14th Sep 2012 09:56 UTC in reply to "RE[3]: Another fallen mobile OS."
galvanash
Member since:
2006-01-25

This would roughly cut your runtime roughly in half:

var t0=new Date().getTime();
var count=10000;
var x=0;
var coords=new Array(count);
var coord_i = null;
var coord_j = null;

for(var i=0; i < count; i++) {
coords[ i ] = [ i,i,i ];
}

for(var j=0; j < count; j++) {
coord_j = coords[j];
for(var i=0; i < count; i++) {
coord_i = coords[ i ];
coord_i[0]=(coord_i[0]+coord_j[1]) * .5;
coord_i[1]=(coord_i[1]+coord_j[2]) * .5;
coord_i[2]=(coord_i[2]+coord_j[0]) * .5;
}
}

for(var i=0; i < count; i++) {
x+=coords[ i ][0]+coords[ i ][1]+coords[ i ][2];
}

var t1=new Date().getTime();
document.getElementById("out").innerHTML=x + ' ' + (t1-t0) + ' ';


Not that is matters much... I'm not suggesting this is as an optimization, I just wanted to point out that only about half of the performance difference is due to object access overhead in your example - the rest is just pure overhead due to it being interpreted. Converting from objects to arrays (with a few minor optimizations here and there) only cuts the runtime in half.

When I profile this in Chrome 90% of the execution time ends up being engine overhead (parsing, compilation, etc). The actual time spent running the meat of the code itself is only about 10-15ms.

Just saying while scripting overhead is not exactly a fixed cost - it tends to be inversely proportional to the amount of code you write. In other words the bigger and more complex the application is, the less it matters...

In a contrived example like this - all you are really demonstrating is that a scripting language has high overhead costs relative to a compiled language when your code is essentially doing nothing useful in a tight loop.

I wouldn't make the arguement that Javascript is an ideal language for doing computationally intensive stuff - but then again that isn't what it is for. Still, it isn't half bad compared with other interpreted languages...

Edited 2012-09-14 10:02 UTC

Reply Parent Score: 3

Alfman Member since:
2011-01-28

galvanash,

"When I profile this in Chrome 90% of the execution time ends up being engine overhead (parsing, compilation, etc). The actual time spent running the meat of the code itself is only about 10-15ms."

Just to be clear, this example did NOT measure script parsing overhead, which was mere milliseconds on my machine and an acceptable one-time cost. What was slow was the run time inside the loop - several seconds in each case. I'm baffled why you're claiming 90% of the execution time is due to "parsing, compilation, etc"? Obviously we can't be talking about the same thing.


"Converting from objects to arrays (with a few minor optimizations here and there) only cuts the runtime in half. "

There are several ways we could have eliminated the objects, but given that they were what I was measuring the overhead of this would have defeated the point.


"In a contrived example like this - all you are really demonstrating is that a scripting language has high overhead costs relative to a compiled language when your code is essentially doing nothing useful in a tight loop."

Maybe I could of/should have implemented a vector multiplication benchmark to be less contrived, but I doubt it would have improved the performance of javascript objects, which is still a problem.


"I wouldn't make the arguement that Javascript is an ideal language for doing computationally intensive stuff - but then again that isn't what it is for."


Fair enough, but if HTML apps continue to displace native ones for things like game engines, that's kind of where we'll end up.


"Still, it isn't half bad compared with other interpreted languages... "

Agree, I think it's a pretty good language & the implementations of it aren't bad either.

Reply Parent Score: 2

galvanash Member since:
2006-01-25

Just to be clear, this example did NOT measure script parsing overhead, which was mere milliseconds on my machine and an acceptable one-time cost. What was slow was the run time inside the loop - several seconds in each case. I'm baffled why you're claiming 90% of the execution time is due to "parsing, compilation, etc"? Obviously we can't be talking about the same thing.


Sorry, I wasn't clear. Your right - we are not talking about the same thing. I wasn't trying to imply that the code above only takes 10-15ms to run in walltime - it takes (on my machine) 1.45s.

What I was saying is that, minus the 10-15ms, the rest of the time is purely parsing, compiling, memory management, type inference, etc. etc. - i.e. non-user code or system code. The actual amount of CPU time spent executing _only_ the actual loops and dong the calculations is 10-15ms. If you want to run it in Chrome and look at the CPU profiler you will see what I am talking about.

In other words, in a perfect world where JS was a compiled to machine code language and memory allocation was perfect and could be done in advance - the code would take around 15ms to run, which is probably very comparable to GCC (if you rewrote the GCC code to allocate the whole chunk of memory in one shot, for example).

But - It is obviously not fair to discount the rest of that time - memory allocation counts too and is real overhead. Its just that since JS does this automatically it isn't done in user code - so it ends up being counted up as "program" time by the profiler. It still matters of course.

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).

That is, by and large, where you will end up seeing all the time go relative to something like GCC - memory allocation, compilation, and garbage collection overhead. Other things (like difference in object access performance) tend to be eclipsed by it. Object access patterns are slower, and that is a real problem, but it isn't the bulk of the performance delta your seeing.

There are several ways we could have eliminated the objects, but given that they were what I was measuring the overhead of this would have defeated the point.


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.

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.

Reply Parent Score: 2