4 ms·

There is some amount of overhead in the VM due to the dynamic nature of JavaScript values and the need for a GC that can't be avoided (even though VM implementa

There is some amount of overhead in the VM due to the dynamic nature of JavaScript values and the need for a GC that can't be avoided (even though VM implementations have had years of effort and optimization put in to address this). You can get around a lot of this by using WASM and having control over the data layout though. In my experiments some times the browser just kicks in and drops some frames in any case. :/ Things just feel a lot smoother in native apps always. Figma for example is doing a pretty good job with a C++ engine running in WASM and using WebGL for their canvas (https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...).

colordrops 6y ago
It can be avoided to a degree if you understand how JavaScript memory allocation works for a particular VM, and use custom methods instead of built-ins for certain operations, to avoid the overhead of the generalized nature of the built-in.
- nikki93 6y ago
  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 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 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#OpTypeVoid https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html...
  - colordrops 6y ago
    Everything you say is correct, but I was just addressing the statement that "it can't be avoided".
    - nikki93 6y ago
      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. :)
      - colordrops 6y ago
        Yes, for sure :)

colordrops 6y ago

It can be avoided to a degree if you understand how JavaScript memory allocation works for a particular VM, and use custom methods instead of built-ins for certain operations, to avoid the overhead of the generalized nature of the built-in.

nikki93 6y ago
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 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 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#OpTypeVoid https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html...
- colordrops 6y ago
  Everything you say is correct, but I was just addressing the statement that "it can't be avoided".
  - nikki93 6y ago
    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. :)
    - colordrops 6y ago
      Yes, for sure :)