3 ms·
Though I have only skimmed the book, this strikes me as an unfair characterization. For example, this case study discusses laziness extensively: <https://haskel
by euiq 3y ago
Though I have only skimmed the book, this strikes me as an unfair characterization. For example, this case study discusses laziness extensively: <https://haskell.foundation/hs-opt-handbook.github.io/src/Case_Studies/klister.html#performance-minded-code-review https://haskell.foundation/hs-opt-handbook.github.io/src/Cas...>
- chowells 3y agoI'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.