janLo
commented
6 years ago Thank you.
I'm generally not a fan of buffering, especially if there is no clear flush-support in the interface you adapt. It always ends u implementing some magic (level-change plus newline in you testcase) that give hard-to-debug issues in some corner-cases.
Your performance test should be normalized I think. Writing a string from flash vs. writing a string bytewise from any other location in ram does not say anything about the performance of the lib, as long as you don't substract the overhead of the flash-read which you have anyway with data comming from flash, regardless what you use to pump it to your log target. If you do so, the numbers should be similar to the byte-wise-test except for the overhead of the extra function calls to size_t Print::println(const __FlashStringHelper *ifsh), size_t Print::print(const __FlashStringHelper *ifsh) and size_t Print::println(void).
The difference between String and const char* might result from different placement in memory or more likely from the extra strlen() in print. That's also something we can't really do anything about.
The general (and huge) difference between single-byte-writes and bulk-writes might come indeed from the (virtual-)function-call-overhead. That's just as it is and we can't do much about it. The only thing is, to tell people, that bulk-writes should be preferred and to make clear, that it is a library for logging messages from a program to various sources that are configurable at runtime, not for high throughput data processing.
I also think, that when you log to a network target or a serial connection, this overhead is not really a big deal.
puuu
Hi, I did some benchmarking of this lib. Writing single bytes or PROGMEM is rather slow compared to String. In addition, as a poc, I tried to implement a prebuffer to avoid iteration of all handler in
ArduinoSimpleLogging::log(). You can find it in my prebuffer branch (puuu/ArduinoSimpleLogging@dd8cef743ef446dd6a109163742ebf0dd219c4aa). The benchmark results (see below), show no big improvement (may be for a high number of handler, but this is unlikely a use case). Thus, the iteration is not the problem. The overhead likely comes from the dynamic binding within the Print class.Anyhow, the benchmark example can be helpful.
Original:
Prebuffer