4 ms·
This sounds silly but I’ve actually turned off garbage collection in short running, small memory programs and gotten a big speed boost. I wonder if that’s some
by bilsbie 2y ago
This sounds silly but I’ve actually turned off garbage collection in short running, small memory programs and gotten a big speed boost.
I wonder if that’s something they could automate? I’m sure there are some weird risks with that. Maybe a small program ends up eating all your memory in some edge case?
- theossuary 2y agoYou'd run into the halting problem. Maybe for some small subset of programs it'd be possible to prove a short runtime, but in general it wouldn't be, so this type of automation wouldn't be impossible. It sounds like maybe you want GCs to be very tunable? That way, developers and operators can change how it runs for a given workload. That's actually one of the (few) reasons I like Java, its ability to monitor and tune its GC is awesome. No one GC is going to be optimal for all workloads/usages. But it seems like the prevailing thought is to change the code to suit the GC where absolutely necessary, instead of tuning the GC to the workload. I'm not sure why that is?
- Arch-TK 2y agoReliable implementation most likely involves solving the halting problem.
- jordan_bonecut 2y agoDisagree, there are practical trivial subsets of the halting problem to which I imagine many short-running scripts would conform.
- Arch-TK 2y agoMost short running scripts call into the standard library or into other packages. I think the trivial subset is too small to bother with such an optimisation.
- tln 2y agoTurn on GC after the first sbrk
- zbentley 2y agoThe first alloc will be really early on in even trivial Python programs, so that’s not a good heuristic. It’s hard to pick a good heuristic in this area because the line between startup time and runtime is so blurry in platforms that support runtime/deferred import and eval.