Newest at the top
| 2026-03-10 13:17:35 +0100 | <comerijn> | Freakie: Also, how big is your live set? |
| 2026-03-10 13:17:29 +0100 | <comerijn> | Freakie: Did you see my comments? |
| 2026-03-10 13:14:57 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-03-10 13:03:50 +0100 | <Freakie> | (assuming you're responding to my previous comments) |
| 2026-03-10 13:03:37 +0100 | <Freakie> | I've been considering doing that as well but it's a larger process |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 13:01:04 +0100 | <c_wraith> | Huh. I never really thought about making each entry in a container its own compact region, but there are cases where that could really reduce GC pressure. (like if there aren't all that many entries, but they have a lot of internal pointers) |
| 2026-03-10 12:59:44 +0100 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-03-10 12:57:09 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 12:56:56 +0100 | <comerijn> | And large live sets are a worst case for GHCs GC approach |
| 2026-03-10 12:56:44 +0100 | <comerijn> | because there's a well known blogpost from ages ago of a company struggle with Haskell GC also for a queue and part of their problem (and, I suspect, yours) was that their inherent problem involved a large liveset |
| 2026-03-10 12:55:16 +0100 | <comerijn> | Freakie: How big is your queue? |
| 2026-03-10 12:51:04 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2026-03-10 12:45:19 +0100 | danz32096 | (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-10 12:42:32 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 12:40:09 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 12:39:45 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 12:37:57 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 272 seconds) |
| 2026-03-10 12:35:34 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 12:35:20 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 12:29:40 +0100 | tristanC | (~tristanC@user/tristanc) tristanC |
| 2026-03-10 12:26:40 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-10 12:23:44 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-03-10 12:21:42 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Quit: CiaoSen) |
| 2026-03-10 12:20:42 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 12:20:08 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 12:11:08 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 12:10:43 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 12:03:43 +0100 | xff0x | (~xff0x@2405:6580:b080:900:cfba:7074:7dbc:e7e9) |
| 2026-03-10 12:00:28 +0100 | <Freakie> | and I'm not sure how exactly to troubleshoot that |
| 2026-03-10 12:00:20 +0100 | <Freakie> | what confuses me a little is that the algorithm has two parts that are supposed to be roughly equal in work intensity but according to my profiles (at least the eventlog2html renders of them), only one of the algorithms are truly "busy" in terms of allocations |
| 2026-03-10 11:58:30 +0100 | <Freakie> | obviously garbage collection is unavoidable but if the runtime explodes for reasons not directly related to the work itself (i.e., not following the asymptotics) then it should be fixed |
| 2026-03-10 11:57:33 +0100 | <Freakie> | jreicher it's "undesirable" in the sense that up to 3/4 of the actual runtime is spent not doing work but just garbage collection |
| 2026-03-10 11:56:58 +0100 | <Freakie> | I've thought about nursery size before but never got around to it, I guess I'll give it a try in not too long |
| 2026-03-10 11:55:31 +0100 | acidjnk | (~acidjnk@p200300d6e700e52576436b4620b4c2a8.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2026-03-10 11:52:22 +0100 | acidjnk_new | (~acidjnk@p200300d6e700e547f0589d3e513577e0.dip0.t-ipconnect.de) acidjnk |
| 2026-03-10 11:48:46 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 11:40:30 +0100 | <probie> | Freakie: does performance improve if you make the nursery bigger? (e.g. try something like `+RTS -A64m -RTS`) |
| 2026-03-10 11:39:41 +0100 | <jreicher> | Some things just have to be GCed; that's the nature of them. (Not the implementation, but the algorithm itself) |
| 2026-03-10 11:39:24 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 11:39:21 +0100 | <jreicher> | Freakie: Just in case it helps, may I question why the garbage collection is "undesirable"? That might sound stupid, but what reason do you have to think it's not needed for your use case? |
| 2026-03-10 11:39:02 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 11:33:24 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 264 seconds) |
| 2026-03-10 11:29:06 +0100 | danza | (~danza@user/danza) (Ping timeout: 248 seconds) |
| 2026-03-10 11:27:11 +0100 | danz32096 | (~danza@user/danza) danza |
| 2026-03-10 11:24:30 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2026-03-10 11:22:00 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2026-03-10 11:21:58 +0100 | <Freakie> | unfortunately purity is pretty essential to what i'm trying to do, which is also why I'm having a difficult time brainstorming alternatives |