11 ms·
>As an aside, compilers have used the trick of not free-ing data structures before, because it provides a significant performance boost. Instead of calling free
by rubber_duck 6y ago
>As an aside, compilers have used the trick of not free-ing data structures before, because it provides a significant performance boost. Instead of calling free on all those billions of tiny data structures a compiler would generate during its lifetime, they just let them leak. Since a compiler is short lived its not a problem, they get a free lunch (pun unintended), and the OS takes care of cleaning up after all is said and done. My point is that this post isn't theoretical, we do deallocation trickery in the real world.
And then someone tries to use your compiler as a service (code analysis, change triggered compiler) and it's a dead end
- yrro 6y agoAs distasteful as leaky code is, is it that bad to run it in a separate process? You get a bit more robustness against crashes as well.
- rubber_duck 6y agoYou want to be able to incrementally update state to get performance out of incremental code analysis (eg. language server implemention for IDE)
- folmar 6y agoThere are more ways to go then that: AST fragment caching, intermediate representation fragment caching and so on. Incremental updates fit some languages better than the others.
- qzw 6y agoWell, then that’s not the original use case anymore, and it’ll have to be re-engineered. In the meantime it may have been used for years and the perf difference may have saved many developer-years collectively across its user base. Surely you’re not suggesting that the compiler developers should be prematurely optimizing for future use cases that they may not even have envisioned.
- rubber_duck 6y agoAvoiding leaks is not optimisation, it's a matter of correctness - not freeing memory is an optimisation based on a very shortsighted assumption that is not practical for any new language (modern languages are expected to come with language server support)
- random314 6y agoYou have not provided any refutation to the OPs argument.
- jashmatthews 6y agoWhy do you say that? Even if you call free immediately after a piece of memory is no longer needed, malloc won’t release that immediately anyway. If this is incorrect, then every modern malloc implementation is incorrect.
- jpitz 6y agoCorrectness means adherence to the spec, not some contrived absolute truth.
- viraptor 6y agoBut the spec usually has some implicit assumptions. Usually it's "app doesn't leak memory" in the same way nobody explicitly specifies "result of an addition of natural numbers should match ...". We don't go around saying "oh, you didn't want modulo 5 arithmetic? You should've put that in the spec, not rely on some contrived absolute truth".
- jpitz 6y agoOkay, but we're talking about an application, a piece of software who's primary intention is to run for a short period of time, parse a text file and transform it. It will be ran many many many times a day by developers whose time is expensive. Language servers are a very new concept in terms of being part of the day-to-day tool chains for most developers. Trading garbage collection for compile time was absolutely a winning strategy for compiler writers. It made them money.
- ycombobreaker 6y agoIn a world where processes can fork-and-exec, nothing about "as a service" changes that. The compiler would just be reinvoked as needed. Converting it into a persistent process breaks a lot more than just allocation optimizations.
- rubber_duck 6y agoBut you want to share state and only update state incrementally on edit to get any reasonable level of performance for stuff like language server code analysis.
- all-fakes 6y agoI'm not sure what the performance overhead would be, but that state can easily be stored on disk.
- tsimionescu 6y agoI'd bet it's a lot harder to rework the compiler to update its state in place than it is to rework it to free memory.