Hello Lennart, Sunday, December 31, 2006, 10:26:24 PM, you wrote:
I think you can be much more productive in optimizing your code if you actually understand what's going on. I usually don't go as far as looking at compiler intermediate code; I usually stick with profiling (or look at assembly code if it's a really performance critical inner loop).
for GHC??? :) if we say about optimizing C programs, old days i usually looked into asm code and then darken and go to rewrote it in asm :) nowadays i look only at memory access patterns, it's enough, at least for a few programs i optimized this year for GHC, i usually know which functions need to become faster, so i personally don't need profiling. moreover, program should be optimized for wide variety of situations, while profiling run shows only one execution scenario. i don't think that looking into STG (don't even said about C--/asm) may help me to optimize program. which program-specific things i can find here, after i've once learned how generation of STG code works?
Then you can start optimizing. That can be by changing algorithm, changing data representation, strictness annotations, etc.
yes, i don't use profiling because i use more specific instruments to investigate performance bottlenecks
It can also be by inserting some INLINE or SPECIALIZE pragmas, but that's more rare (don't get me wrong about those pragmas, I introduced them in Haskell with hbc). But I think just adding pragmas willy-nilly is a bad idea; I find that most serious performance problems cannot be solved by those means, instead you need a higher level approach.
i proposed it as fast approach to raise performance, as alternative to your suggestion to profile and read code, where you not said anything about changing algorithms :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com