Optimization for Logging RAM usage #724
Conversation
…gging is activated, otherwise does not allocat any data.
| #endif | ||
| #endif // USE_DLT | ||
| } catch (const std::exception& e) { | ||
| std::cout << "\nVSIP: Error destroying message class: " << e.what() << '\n'; |
There was a problem hiding this comment.
Wouldn't cerr be more appropriate?
| return active_; | ||
| } | ||
|
|
||
| inline std::string str() const { |
There was a problem hiding this comment.
I'm curious if a string_view would be more appropriate here.
There was a problem hiding this comment.
I am not 100% sure, std::stringstream::str() constructs a new string anyway and wouldn't std::string_view then point to a temporaray object? Maybe I am wrong ...
There was a problem hiding this comment.
I could be entirely wrong, but I think what happens here that a new std::string is constructed (with allocation) here when buffer_.str() is involved, and then the string stream copies the contents of this into the new string it is constructing. If this were a std::string_stream, we may save on one allocation. If I'm right this could be considerable on platforms like QNX.
I suppose the only way to know would be to test it out. I can try to set up something small on godbolt.
There was a problem hiding this comment.
I set up a minimal example in godbolt and found exactly where I was confused. I didn't see that data_ was a stringstream. So there's no savings to be had it seems.
That said, C++20 has a stringstream::view that returns a string_view, unfortunately nothing appears to support it yet, so maybe one day...
This change is an improvement to the message class of the internal logger. Instead of checking if logging is active in the destructor this is now done in the constructor. If logging for the specific level is deactivated no data is written to the internal std::stringstream and thus the performace is improved.