2 ms·
I get it. And I do wish some systems were quicker to let the OS clean up after them on exit. For instance, the other day loaded a CSV with about 20 columns and
by kstrauser 2y ago
I get it. And I do wish some systems were quicker to let the OS clean up after them on exit. For instance, the other day loaded a CSV with about 20 columns and 10M rows into a list of Python tuples so I could poke at them a bit. That took a short while and I was ok with that. I was more surprised when I closed the REPL and it hung for way longer than expected as it freed a couple hundred million objects.
Now it could’ve been the case that some of those objects had a __del__ method that needed to be called or something. Absent that case, I’d have preferred the process just exited and been done with it.
If that were a program that ran synchronously from a shell script, the shutdown GC time would’ve been nearly as long as the data loading time. Maybe Python could benefit from a fast_shutdown_GC function that only calls free() if an object is something with a non-trivial delete method. Otherwise, skip it and let the OS do its voodoo it does so well.
I’m picking on Python here because that’s where I last saw this. The basic idea applies in lots of other cases though.