Comment by IsaacSchlueter | Hacker News Reader

Comment by IsaacSchlueter | Hacker News Reader

I have a problem with this line:

    Objects in JavaScript are not cheap, they need to carry 
    around lots of extra information and can be many times 
    larger than their C style counterparts, moreover property 
    access is slow.

It's easy to say "X is not cheap, Y is slow".

It's much more valuable to actually prove it with numbers that show where it's fast and where it's slow.

In my experience, object creation and property access is almost never the bottleneck, and GC pauses only are relevant (in v8 at least) if you're leaking a large number of objects, especially where those objects are of mixed generations. (Ie, have a lot of long-lived and short-lived objects that refer to one another and occasionally leak.) That is, if you are getting hit with long GC pauses, then it's worth re-thinking your design and tracking down objects that may be leaking.

Newer JS engines (ie, the ones that implement TypedArrays) already highly optimize object creation and property access. The benefit therefor seems slim and highly niche. Looking at the generated code, it seems like the debugging cost is going to be very high, and it drastically increases the number of lines that the programmer has to write, which will increase bugs.

I could see the value in certain niche situations, but I would really like to see the performance characteristics explored more fully.

    It's easy to say "X is not cheap, Y is slow".

Yeah, I probably wouldn't have worded it that way. I think the better way to look at it is, it's hard to know how to predict the performance of JavaScript, given the complex, dynamic, heuristic optimizations performed by modern engines. This project is better thought of as an attempt to build a dialect of JS that can be more easily tuned for performance, because its performance model is simpler than that of JS.

If I were going to try to make that claim more precise, I might do some experiments to demonstrate the high variance of object performance in modern JS engines.

    I could see the value in certain niche situations...

That's really the idea. This isn't meant to be an alternative to JS, but rather a tool for performance-sensitive kernels. Interoperability will therefore be key, because it has to be easy to write just a small component of a larger app in this dialect while smoothly integrating into the rest of the app.

    ...but I would really like to see the performance characteristics explored more fully.

Perhaps. I'm skeptical of our ability to accurately measure general claims like "objects are slow" or "X is easier to program in than Y" or "*JS is easier to performance tune than JS." But I do think it's easier to evaluate those claims, at least informally, after you've built something you can experiment with. Hence this experiment!

I have problem with this line:

  The benefit therefor seems slim and highly niche.

It's easy to say "situation X does not occur often".

It's much more valuable to actually prove it with numbers that show how often it is used across the sum of problem domains out there that you might not be aware of.

We are all solving different problems. I'm running in memory stream processing. Objects in Javascript and associate GC overhead are a massive hindrance in my domain.

For me this experiment is of incredible value.

This! There are no benchmarks given or otherwise proof that this is faster.

With the example given of the linked list, it's claimed that the JS version is slow. However running it myself, I find their JS version actually runs faster in FF and Chrome then the JC one.

Reply on news.ycombinator.com