4 ms·

Garbage collection contributes pretty little to Javascript's performance issues. Unless you deal with some allocation happy data structures, such as linked list

Garbage collection contributes pretty little to Javascript's performance issues. Unless you deal with some allocation happy data structures, such as linked lists.

austincheney 9y ago
GC is the primary performance killer for persistent CPU intense applications, which is why there aren't many such applications written in JavaScript. The thread is locked when GC happens. In most other JavaScript applications GC is hard to notice, because it typically runs once the application has finished executing.
- vardump 9y ago
  CPU intensive applications don't usually allocate that much. Excessive allocation makes also other languages, such as C++, very slow.
- imtringued 9y ago
  GC is not a problem for CPU intense applications. The fundamental problem with a GC is that all threads must be stopped to perform the garbage collection. GC pauses are a problem for realtime applications because an unpredictable GC pauses can blow your time budget of 16ms (or even less) per "tick". The only way to avoid this is by not allocating anything during the realtime segments. Since the GC "infects" your entire program you are also not allowed to allocate anything during the non realtime segments. So you might as well just write C++ code. If the heap is large enough (several dozen gigabytes) the GC pauses may cause latency spikes that last more than a second.
- fulafel 9y ago
  See eg https://v8project.blogspot.com/2017/11/orinoco-parallel-scavenger.html https://v8project.blogspot.com/2017/11/orinoco-parallel-scav... - some JS GCs are parallel and it's not the case that the "thread is locked" for the whole duration of the GC.
vanderZwan 9y ago
What you say is true for regular websites, but game code has different needs than the type of JS you normally use in websites. I've seen people do some very naive stuff, like: var particle = { color: randomColor(), position: new Point(x, y), // number of frames the particle lives decayIn: 50 + Math.ceil(Math.random()*100), }; ... for very short-lived particle effects. This does not scale if you want to draw thousands of particles that each last a few seconds. If they were smarter about it, they could create a pre-allocated "pool" using a maximum nr of particles and re-use them. Likely to be even faster would be preallocating one Uint32Array (for color), two Float64Arrays (one for x and y), and one Uint8Array (for decayIn), and then use an index to look up an individual particle's color, x, y, and remaining frames. Anyway, what I'm saying is: idiomatic JS definitely can result in garbage collection-related bottlenecks for game development, but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays).
- vanderZwan 9y ago
  > but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays). Too late to edit, but this really should have finished with: ... at the cost of code that is more verbose yet the opposite of self-documenting, inherently frail even if you put wrapper-functions around those typed arrays, and likely to require massive changes all over the code-base for the smallest updates. In my opinion, unless you have a really good reason to not use alternative options like WASM or Emscripten, trying to squeeze that kind of performance out of vanilla JavaScript it's unlikely to be worth the technical debt.

Garbage collection contributes pretty little to Javascript's performance issues. Unless you deal with some allocation happy data structures, such as linked lists.

austincheney 9y ago

GC is the primary performance killer for persistent CPU intense applications, which is why there aren't many such applications written in JavaScript. The thread is locked when GC happens. In most other JavaScript applications GC is hard to notice, because it typically runs once the application has finished executing.

vardump 9y ago
CPU intensive applications don't usually allocate that much. Excessive allocation makes also other languages, such as C++, very slow.
imtringued 9y ago
GC is not a problem for CPU intense applications. The fundamental problem with a GC is that all threads must be stopped to perform the garbage collection. GC pauses are a problem for realtime applications because an unpredictable GC pauses can blow your time budget of 16ms (or even less) per "tick". The only way to avoid this is by not allocating anything during the realtime segments. Since the GC "infects" your entire program you are also not allowed to allocate anything during the non realtime segments. So you might as well just write C++ code. If the heap is large enough (several dozen gigabytes) the GC pauses may cause latency spikes that last more than a second.
fulafel 9y ago
See eg https://v8project.blogspot.com/2017/11/orinoco-parallel-scavenger.html https://v8project.blogspot.com/2017/11/orinoco-parallel-scav... - some JS GCs are parallel and it's not the case that the "thread is locked" for the whole duration of the GC.

vanderZwan 9y ago

What you say is true for regular websites, but game code has different needs than the type of JS you normally use in websites. I've seen people do some very naive stuff, like: var particle = { color: randomColor(), position: new Point(x, y), // number of frames the particle lives decayIn: 50 + Math.ceil(Math.random()*100), }; ... for very short-lived particle effects. This does not scale if you want to draw thousands of particles that each last a few seconds. If they were smarter about it, they could create a pre-allocated "pool" using a maximum nr of particles and re-use them. Likely to be even faster would be preallocating one Uint32Array (for color), two Float64Arrays (one for x and y), and one Uint8Array (for decayIn), and then use an index to look up an individual particle's color, x, y, and remaining frames. Anyway, what I'm saying is: idiomatic JS definitely can result in garbage collection-related bottlenecks for game development, but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays).

vanderZwan 9y ago
> but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays). Too late to edit, but this really should have finished with: ... at the cost of code that is more verbose yet the opposite of self-documenting, inherently frail even if you put wrapper-functions around those typed arrays, and likely to require massive changes all over the code-base for the smallest updates. In my opinion, unless you have a really good reason to not use alternative options like WASM or Emscripten, trying to squeeze that kind of performance out of vanilla JavaScript it's unlikely to be worth the technical debt.