Ondrej Medek

More efficient is to use string concat then `parts` array, e.g. see https://jsperf.com/javascript-concat-vs-join/2

Duplicate of #69

@megahertz 👍 for the quick fix. I just do not understand your note: "I would prefer slower performance rather than loosing critical log records on crash." IMO even the current...

Note: pino hooks handlers to beforeExit, exit, uncaughtException, SIGHUP, SIGINT, SIGQUIT, SIGTERM to flush async logger, see https://github.com/pinojs/pino/blob/master/docs/asynchronous.md#caveats (But I do not find it necessary.)

* I think the problem is not in the initialization, but in the fact, then the `bytesWritten` counters are independent. So, if I have `N` windows writing to the same...

Which pitfalls has such implementation which sends all over IPC? Could a plain socket/TCP connection do better? Note: the note was about log overwriting, but the `maxSize` should be added,...

Hmm, digging through the VS Code code seems like they use net sockets by named pipe, see [`ipc.net`](https://github.com/microsoft/vscode/blob/main/src/vs/base/parts/ipc/node/ipc.net.ts), for most of IPC and the logging, too. (Even `process.send` transport is...

@megahertz I have done custom Electron IPC transport and logging to file with Electron 12 and seems to me IPC is not the bottleneck. I have tested 100000 logs in...

And on the renderer side, `ipcRenderer.send` maybe used with [`window.requestIdleCallback()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback) and a queue with a limit to keep renderer responsive even when under heavy log load.

Is it necessary to support all of these .NET versions when they are backward compatible?