Newest at the top
| 2026-03-07 11:57:14 +0100 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2026-03-07 11:57:14 +0100 | <Leary> | @where paste |
| 2026-03-07 11:56:45 +0100 | <Leary> | Guest89: The problem is less likely to be allocations than unnecessary retention or unwanted thunks bloating your representation. Allocating is almost free, holding onto it is what costs you. In any case, I would start by heap profiling by type, which doesn't actually require a profiling build. |
| 2026-03-07 11:56:37 +0100 | <Guest89> | I guess I'll just write it down: |
| 2026-03-07 11:55:58 +0100 | <Guest89> | not familiar |
| 2026-03-07 11:55:46 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 248 seconds) |
| 2026-03-07 11:55:46 +0100 | <haskellbridge> | <sm> it's a lot easier if you use the matrix room |
| 2026-03-07 11:55:31 +0100 | <Guest89> | or should I just put it in writing |
| 2026-03-07 11:55:26 +0100 | <Guest89> | is it possible to paste pictures over IRC? |
| 2026-03-07 11:55:14 +0100 | <haskellbridge> | <sm> well, how much memory does +RTS -s say is being allocated ? |
| 2026-03-07 11:53:30 +0100 | <Guest89> | I just don't see how garbage collection can dominate the runtime so much |
| 2026-03-07 11:52:49 +0100 | <haskellbridge> | <loonycyborg> ye it's just an example |
| 2026-03-07 11:52:40 +0100 | <Guest89> | most of the actual allocation happens within the core algorithms, but I've also tried varying levels of strictness there |
| 2026-03-07 11:52:17 +0100 | <Guest89> | I've tried both strict and non-strict versions of foldl, and I didn't seem to see any issues |
| 2026-03-07 11:51:53 +0100 | <haskellbridge> | <sm> it requires investigation, there's no way round it |
| 2026-03-07 11:51:37 +0100 | <haskellbridge> | <loonycyborg> Maybe it's thunk explosion somewhere, like from foldl |
| 2026-03-07 11:51:26 +0100 | <Guest89> | obviously you can't get the performance *that* close, at least not in terms of memory, but as things are it's both an absurd difference and not feasible |
| 2026-03-07 11:50:56 +0100 | <Guest89> | I understand, but the issue is that my implementation uses something like 100 times as much memory as a reference implementation in C++ |
| 2026-03-07 11:50:51 +0100 | <haskellbridge> | <sm> the time and space profile will show you the top users of time and space, and will show you any crazy large call counts indicating things called too often |
| 2026-03-07 11:50:38 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 11:50:08 +0100 | <haskellbridge> | <sm> it may be normal that the program uses 2 or even 3 times what you think, depending how you measure it, because of how GC works (making copies) |
| 2026-03-07 11:49:57 +0100 | Ranhir | (~Ranhir@157.97.53.139) Ranhir |
| 2026-03-07 11:49:28 +0100 | <Guest89> | it's supposed to be an implementation of I/O efficient BDD (binary decision diagram) algorithms which necessarily generates a lot of data so I need some way to minimize overhead where it's reasonable |
| 2026-03-07 11:48:33 +0100 | <Guest89> | I assume there is some structure in my code that exacerbates the problem but I can't really see where |
| 2026-03-07 11:48:10 +0100 | <Guest89> | I've already been trying to use GHC.Compact but it doesn't seem to have affected runtimes at all |
| 2026-03-07 11:47:48 +0100 | <Guest89> | I have some data that suggests that the data itself isn't fragmented but the program allocates about twice as much as it uses, which also seems excessive |
| 2026-03-07 11:47:46 +0100 | <haskellbridge> | <loonycyborg> https://github.com/ezyang/compact <- this might help with excessive gc times |
| 2026-03-07 11:46:33 +0100 | <haskellbridge> | <sm> yes, +RTS -s is useful |
| 2026-03-07 11:46:16 +0100 | <Guest89> | it's verbose but I can navigate it at least? |
| 2026-03-07 11:45:59 +0100 | <Guest89> | I've mostly relied on the metrics provided by different RTS options so far |
| 2026-03-07 11:45:32 +0100 | <Guest89> | I'll be honest, I haven't figured out how to interact with packages like that yet; I've used stuff like eventlog2html but compiled as a separate executable |
| 2026-03-07 11:45:29 +0100 | <haskellbridge> | <sm> and you're right, it's overallocating (garbage collection should be a small percentage of your run time) |
| 2026-03-07 11:44:12 +0100 | <haskellbridge> | <sm> it will be hard to understand completely, but full of useful information. You can also process it with https://hackage.haskell.org/package/profiterole which makes it more readable. |
| 2026-03-07 11:42:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-07 11:41:50 +0100 | <haskellbridge> | <sm> you must make a profiling build of your app, then run it with special flags |
| 2026-03-07 11:41:21 +0100 | <haskellbridge> | <sm> hi Guest89 . It's not the easiest process, but it will be useful to generate a simple time and space profile - the profiling chapter in the GHC Users's Guide should tell how |
| 2026-03-07 11:40:11 +0100 | <Guest89> | garbage collection takes 3 times as long as the code itself for example, which I think seems very excessive. I've been trying to play around with things like ghc-compact but it didn't seem to help things any |
| 2026-03-07 11:39:41 +0100 | <Guest89> | written. would anyone be willing to help me figure things out? |
| 2026-03-07 11:39:40 +0100 | <Guest89> | hello; I'm trying to profile an application that is rather performance sensitive and I'm hoping to reduce allocations as much as possible (this is for the purposes of a master's thesis I'm working on), but I'm having a little trouble isolating the hotspots in my code and understanding whether or not my code itself is overallocating as it is |
| 2026-03-07 11:39:06 +0100 | Beowulf | (florian@sleipnir.bandrate.org) (Quit: = "") |
| 2026-03-07 11:37:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 11:36:19 +0100 | Guest89 | (~Guest89@185.45.21.144) |
| 2026-03-07 11:29:48 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 264 seconds) |
| 2026-03-07 11:26:34 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-07 11:26:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-03-07 11:25:05 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-07 11:23:59 +0100 | img | (~img@user/img) img |
| 2026-03-07 11:22:44 +0100 | img | (~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-07 11:21:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 11:19:03 +0100 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |