4 ms·

The description says "the compilation builds a version of the NanoLog library that is non-portable, even between compilations of the same application". They als

The description says "the compilation builds a version of the NanoLog library that is non-portable, even between compilations of the same application". They also mention that a decompressor application also gets built and can be used to reconstitute a human-readable version of the log file. My question is, is the decompressor application also tightly coupled to a particular compilation? It sounds like the answer is yes, but I'd really like to be wrong about that. That would really suck for cases where you want to store old log files for later use. You'd have to also store a copy of the decompressor program that corresponds to each log file. Or you'd have to convert to human-readable format before storing the log files, which loses a number of the benefits of the binary log format (compact size, faster to parse).

nemetroid 7y ago
In the related paper[1], this paragraph (5.1.2) strongly suggests that the decompressor is non-portable as well: > NanoLog performs best when there is little dynamic information in the log message. This is reflected by staticString, a static message, in the throughput benchmark. Here, NanoLog only needs to output about 3-4 bytes per log message due to its compaction and static extraction techniques. 1: https://www.usenix.org/conference/atc18/presentation/yang-stephen https://www.usenix.org/conference/atc18/presentation/yang-st...
Mathnerd314 7y ago
Did you skip over the section where they say to use the C++17 version that doesn't have this issue? I looked in the paper to find the explanation for why the preprocessor version is non-portable; there wasn't anything clearly written but it seems to be related to how it assigns unique ID's to log statements.