1. 5

    1. 4

      In order to minimize the impact of logging on the main application – and therefore on the host – it’s important to avoid large batches of work. They may clog the PCI bus at the wrong moment.

      I don’t know what kind of programming this guy does, but I feel like we are not on the same level — I mostly write async backends where the cost of logging is very low compared to network latency and such. I don’t even think about clogging the PCI bus — I don’t think I am anywhere close to the amount of throughput there, considering what the PCIe transfer rate is.

      Awesome article but it would be good to give some examples of where these techniques are needed and why, otherwise I feel like it is over engineered (and I am sure the author had good reason to use these techniques)!

      1. 2

        High frequency trading, probably. So not actually useful, but the ideas and ways of thinking may be translatable to other domains, even if not the exact specific techniques.

        1. 1

          I would not say that it is not useful — some of the ideas could be applicable to other domains. High-traffic deployments can benefit from cheap logging, and so can embedded systems. But it might be useful to add a disclaimer to say that this is not something we normies need (not yet anyways, but you can be sure I’ll cook up some project idea to have an excuse to play with it at some point, hehe).

    2. 2

      Much of this seems applicable in any low-level language.

      (Meanwhile I am working on reducing CPU usage by fixing some logging code that indirectly does an OpenSSL SSL_write for every byte—slight exaggeration, but only slight—which results in massive increase in bandwidth and massive CPU usage as it encrypts and decrypts lots of padding or something. And this person is talking about shaving off 6ns 😭)

    3. 1

      I believe slog with slog-async can/does all of it already.