4 ms·
It's probably worth mentioning that the GC cycles start to take upwards of one second at around 500mb of RAM usage with lots of small objects. This limit doesn
by glenjamin 15y ago
It's probably worth mentioning that the GC cycles start to take upwards of one second at around 500mb of RAM usage with lots of small objects.
This limit doesn't stop you using NodeJS, but it's definitely something newcomers should be made aware of before they start writing database servers or making heavy use of a naive in-memory cache through an object literal.
Hopefully when the new GC gets rolled out we'll really be able to let loose with the RAM usage.
- Uchikoma 15y agoFunny how all VMs go through this. Remember when JVM GC pauses killed websites - and how over the years this was fixed by better - non pausing - GC strategies.
- monopede 15y agoThat's very easy to explain. A low-pause GC requires a concurrent garbage collector. Writing a correct concurrent garbage collector is VERY tricky, so you usually start with something much simpler. Concurrent GCs typically also add overhead to the mutator (the user program), so it tends to be a trade-off of high throughput vs. short maximum pause times. As an example Java's G1 collector ("Garbage First") took a team of experts about 5 years to get correct. OTOH, writing a standard (single-threaded) Cheney-style copying GC can be done in a few days. Actually, the more time consuming part for me was to get all the pointer information to the GC.