4 ms·
I've skimmed that section and.. it's a case study of tracking down and fixing some space leaks. That's not what I'm talking about. I'm talking about understand
by chowells 3y ago
I've skimmed that section and.. it's a case study of tracking down and fixing some space leaks.
That's not what I'm talking about. I'm talking about understanding laziness, such that you don't ever write code that's as bad as the starting point there. Treat space use as a correctness property, and make use of documented space invariants to show what you intended. When you do all of this properly, space use becomes a very tractable local property. And sure, some bugs will slip in - but you probably will find them with much less work than the writeup in the section you linked to.
- euiq 3y agofair enough—the book certainly seems to favor "make things strict enough so that your usual algorithms work" over "rewire your brain for laziness"
- doyougnu 3y agoI think that is a fair assessment of that chapter. The goal of the chapter was to take a project that has never done any kind of optimization and to show an optimization engineering pass. Basically one has to be sure the implementation doesn't have any obvious easy to fix leaks before considering a different algorithm or something like that. So I would argue that the real message of that chapter is demonstrating, step-by-step the methods used to find the memory leaks: info-table profiling and biographical/retainer profiling and ticky-ticky profiling.