[azakai]

I see now what you are saying about that issue, NaNboxing makes it worse but at core it is a deoptimization issue. Which is good, I hope this is fixed soon (so emscripten-compiled code runs more consistently across browsers).

> I am not sure I entirely understand. If you are running in a cold code then performance does not matter and you can tolerate quickly allocating a small amount of boxes which will be as quickly reclaimed by scavenger once you are done with them. If you are running in an hot code --- then it should be optimized in a way that minimizes the number of boxes produced.

Let's say that performance matters in the application, but it is huge in code size and all the code matters, not a few small parts. Would you call all the code hot, and would v8 optimize the entire application? (i.e., how is 'hot' defined in v8?)

[mraleph]

Hot currently is defined as "function called more than X times" and "function contains a loop that took a backedge more than Y times". So it is defined per-function basis.

I can hardly speculate how V8 will behave on some abstract application. That is really highly dependent on how code looks like. But ultimately V8 will try to optimize everything that falls under criteria outlined above.

[azakai]

I see, thanks.

I ask because performance of small benchmarks has been quite good, except for the uint32 issue mentioned above, often around 3x slower than native code - but on very large codebases it is often much slower, and I do not know why.

[mraleph]

Unfortunately (as you probably know yourself) I don't have a magical answer that would speed everything up. As for V8 there is quite a number of limits that you might be hitting with generated code (e.g. number of locals, size of the function etc) and there can be some bugs or non-done-yet thingies affecting performance. Profiling and looking at the generated code (and filing bugs) is the only suggesting I can give here.

[azakai]

Ok, yeah, I understand there is no simple answer here. Thanks for your clarifications earlier.