3 ms·
GC is the primary performance killer for persistent CPU intense applications, which is why there aren't many such applications written in JavaScript. The threa
by 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 agoCPU intensive applications don't usually allocate that much. Excessive allocation makes also other languages, such as C++, very slow.
- imtringued 9y agoGC 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 agoSee 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.