6

I am working on a heuristic search project and once I got a working example, I started to benchmark it just to discover that it was not fast enough. I started profiling it (not really an expert on how to do that for a project either) and discovered that it spends 80% of the time in garbage collection.

I tried to find on the internet how to reduce this time, but I have not been able to find something general. Can someone recommend some literature on the topic, or give some general guidelines on how garbage collection works? How should I try to look for the problem and what can be causing it?

Edit: I'm not talking that much about tools to profile the code, for which it's true that Krom's suggested question is on point Rather than that I'm looking for general tips and practices to make (specifically) garbage collection take less time, since the abstractions in the language make it harder to think about what can be going on exactly. Is there something like that?

Diego Vicente
  • 375
  • 3
  • 12
  • Have you checked the `.prof` yet? – Zeta Jun 28 '17 at 13:15
  • Possible duplicate of [Tools for analyzing performance of a Haskell program](https://stackoverflow.com/questions/3276240/tools-for-analyzing-performance-of-a-haskell-program) – typetetris Jun 28 '17 at 13:35
  • [this](https://wiki.haskell.org/Performance) might be helpful too – typetetris Jun 28 '17 at 13:37
  • 1
    @Zeta: yes, that's how I discovered that GC is taking 80% of the time; my problem is that I don't know how to reduce that time consumption. – Diego Vicente Jun 28 '17 at 13:50
  • @Krom my question was more related to specific techniques to reduce the GC time, rather than profiling the code – Diego Vicente Jun 28 '17 at 13:51
  • @DiegoVicente the `.prof` should show where you allocate memory, unless you forgot to add cost centers. Did you use `{-# SCC ... #-}` or `-auto-all`? The generic technique is: "make your code allocate less and remove space leaks". – Zeta Jun 28 '17 at 13:54
  • There is no way around profiling, what is putting such pressure on GC and solve this. That is done by profiling. Are you stacking thunks? -> Restructure code, use strictness annotations. Are you creating an unreasonable amount of garbage due to immutable data structures? Use mutable ones. – typetetris Jun 28 '17 at 13:58
  • @Zeta oh, I didn't try to add my own cost centers; thank you! I'll try to find the leak that way. – Diego Vicente Jun 28 '17 at 13:58
  • @Krom Ok, I'll try to use all those tips tackle the problem down. Thank you! – Diego Vicente Jun 28 '17 at 13:59
  • Chapter 7 (and 8.2) of the [GHC Users Guide](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/). – ja. Jun 28 '17 at 16:45
  • 1
    Any question about operational semantics should include the code in question. You begin looking for the problem by analyzing the code - without the code, nobody can actually tell you what might need to be done. Furthermore, certain programs create a lot of garbage (and hence spend a lot of time doing GC) because that is what maximizes the speed of the program. That is, time and space complexity are very often tradeoffs for each other. But without seeing the program, its impossible to know. – user2407038 Jun 28 '17 at 21:16
  • @user2407038 I was able to spot the problem and asked a [new question with the code](https://stackoverflow.com/questions/44889398/priority-queue-based-on-heap-causes-a-lot-of-garbage-collection-in-haskell). Sorry for the inconvenience – Diego Vicente Jul 03 '17 at 15:35

0 Answers0