Lighterweight Platform.silentHandler

[omnibs]

While digging for space leaks in Nri's Amazonka wrapper, I noticed a bunch of TracingSpan and TracingSpanDetails building up where a Platform.silentHandler was being used.

Digging into it, I noticed silentHandler uses mkHandler, which creates lots of IORefs which, in silentHandler's case, were never useful.

I made an internal nullHandler function specifically for the public silentHandler that does no IO.

I still kept silentHandler : IO LogHandler, even tho I could have made it pure, to keep it a non-breaking change, because I was lazy.

[brian-carroll]

It would be nice to mention memory leaks specifically.
Engineers often disagree on the importance of efficiency, whether certain special cases are justified, etc.
But a memory leak is pretty objective. And if someone changes this code, they need to watch out for that.

[omnibs]

Ah, I didn't mention memory leaks because I'm not really sure the leaks are caused by mkHandler. We use mkHandler all the time with other LogHandler instances. What's special about silentHandler? Remember we didn't see leakage in high-throughput apps like HQE before #134? Every request in HQE uses mkHandler.

I think it might be more of an issue of how the handler is being used, than the handler itself.

There's this old article by Edsko de Vries on Conduit and space leaks, which I don't really follow, that reinforces the suspicious there's something about our usage that makes this leak. It seems it's not exactly what Edsko describes tho, because -fno-full-laziness didn't help.

This is also why I was more keen on removing the unused silentHandler logger in our Amazonka wrapper, than fixing it to actually log things to the request's tracing span. If I knew what's really causing the leak and how to fix it, I'd rather have logs.

[omnibs]

Although I could leave a word of warning wrt this whole situation. Someone might be grateful.

[brian-carroll]

Yeah exactly 👍

[brian-carroll]

Perfect, thanks!