You might reduce it for sure, but you aren't going to avoid it entirely. The best is when it gets to a tracing JIT and all of the calls have a similar codepath. And the fact that you need to jump through hoops like this instead of just writing normal code and expect it to do only what you're saying instead of doing a bunch of other stuff too, is part of the problem. Like, what you are saying, is exactly the point: the default method of working introduces performance issues and makes it hard to reason about performance in a way that is predictable, requiring you to understand VM internals and just 'hope' that the runtime works it out. So you are essentially saying that the default path is slower. It's also hard to ensure that your objects have a predictable layout in memory (important for cache issues) other than by just using a `TypedArray` and re-inventing structs within that.
The semantics of JS itself make certain optimizations hard. Even a simple VM can do arithmetic faster than no-JIT Node.js and JSC: https://godbolt.org/z/5GbhnK (an example I've been working on lately) (I'm interested in no-JIT perf because that's what you're allowed to do in your own runtime on iOS). LuaJIT is the best at this, and even there Lua's semantics prevent certain optimizations--https://news.ycombinator.com/item?id=11327201
For sure, I think you can mitigate it, but I would take that as being different from avoidance (simply because there are other languages / runtimes where there is clear actual avoidance). Regardless I think we have enough details in the conversation at this point to understand what each other is saying. :)
The semantics of JS itself make certain optimizations hard. Even a simple VM can do arithmetic faster than no-JIT Node.js and JSC: https://godbolt.org/z/5GbhnK (an example I've been working on lately) (I'm interested in no-JIT perf because that's what you're allowed to do in your own runtime on iOS). LuaJIT is the best at this, and even there Lua's semantics prevent certain optimizations--https://news.ycombinator.com/item?id=11327201
I think you can do a lot better with a bytecode that is more 'typed', like in SPIR-V: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html...