Re: boost.log's text_multifile_backend is not performant on windows - perhaps it should be documented?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-03-04 09:41:57

On 3/3/21 11:00 PM, Nicholas Neumann via Boost wrote:
> I recently moved a project to boost.log from a homemade logger. I had
> something like text_multifile_backend, so finding that as a drop-in
> replacement was awesome.
> 
> Unfortunately, the performance when using text_multifile_backend on windows
> is really bad, because the repeated file close operations (one per log
> record) are unusually slow on windows. Repeatedly logging a string to the
> same file via text_multifile_backend results in throughput of about 200 log
> entries per second.
> 
> Just to quickly prove it is unique to windows, I made a simple program that
> just opens, appends a single line, and then closes, an ofstream in a loop.
> On a high-end windows machine with nvme ssd, 1000 iterations takes 2600ms.
> On an older linux box with a sata ssd, the same takes 16ms.
> 
> What do others think about adding a note in the documentation about this
> performance issue? It's bad enough that I think anyone on windows would
> want to avoid the backend. It's not the backend's "fault" at all; I could
> see some options for improving performance of the backend on windows, but
> they definitely complicate the simplicity of the current approach.

I'm not sure I feel good about documenting it, as it doesn't really 
solve the problem. I suppose, I could add a cache of the least recently 
used files to keep them open, but that cache would be ineffective if 
exceeded, which can happen in some valid cases (e.g. writing logs 
pertaining to a given dynamically generated "id" to a separate log). And 
it would only be useful on Windows.