compiler
/
fmtlog
mirror of https://github.com/MengRao/fmtlog.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update README.md

This commit is contained in:
Meng Rao 2023-03-26 10:40:59 +08:00 committed by GitHub
parent aa7ed208a5
commit 5aea0764c8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -196,7 +196,7 @@ Note that the throughput of Nanolog is not comparable here because it outputs to
How can fmtlog achieve such low and stable latency? Two key optimization techniques are employed inspired by Nanolog:
One is allocating a single producer single consumer queue for each logging thread, and have the background thread polling for all these queues. This avoids threads contention and performance will not deteriorate when thread number increases. The queue is automatically created on the first log msg of a thread, so queue is not created for threads that don't use fmtlog. The thread queue has a fixed size of 1 MB, and it takes a little time to allocate the queue. It's recommended that user actively calls `fmt::preallocate()` once the thread is created, so even the first log can have low latency.
One is allocating a single producer single consumer queue for each logging thread, and have the background thread polling for all these queues. This avoids threads contention and performance will not deteriorate when thread number increases. The queue is automatically created on the first log msg of a thread, so queue is not created for threads that don't use fmtlog. The thread queue has a default size of 1 MB(can be changed by macro `FMTLOG_QUEUE_SIZE`), and it takes a little time to allocate the queue. It's recommended that user actively calls `fmt::preallocate()` once the thread is created, so even the first log can have low latency.
What happens when the queue is full? By default, fmtlog simply dump addtional log msgs and return. Alternatively, front-end logging can be blocked while the queue is full by defining macro `FMTLOG_BLOCK=1`, then no log will be missing. User can register a callback function when log queue is full by `fmtlog::setLogQFullCB(cb, userData)`, by which user can be aware that the consumer(polling thread) is not keeping up. Normally, the queue being full is seldom a problem, but incautious user could leave log statements that are invoked in an unexpected high frequency, e.g. a tcp client spamming with "Connection refused" errors without a connection retry delay. To handle this problem in an elegant way, fmtlog provides a log macro which limits frequency of this log: `FMTLOG_LIMIT` and 4 shortcuts `logdl`, `logil`, `logwl` and `logel` respectively, user needs to pass the mininum interval in nanosecond as the first argument, e.g.
```c++