easylogging++: faster access to logging #4840
Conversation
| @@ -552,7 +552,7 @@ typedef std::ostream ostream_t; | |||
| typedef unsigned int EnumType; | |||
| typedef unsigned short VerboseLevel; | |||
| typedef unsigned long int LineNumber; | |||
| typedef std::shared_ptr<base::Storage> StoragePointer; | |||
| typedef base::Storage *StoragePointer; | |||
There was a problem hiding this comment.
This now leaks a global base::Storage object (elStorage). This exists for the lifetime of the system anyway - intentional?
| { | ||
| return getresetELPP(false); | ||
| if (!el::base::elStorage) | ||
| el::base::elStorage = new el::base::Storage(el::LogBuilderPtr(new el::base::DefaultLogBuilder())); |
There was a problem hiding this comment.
The construction of this variable is no longer thread-safe. Do all the apps call a log function before starting threads? Is that an acceptable risk? Accessing the thread-safe atomic (the implicit static init bool) should be fairly quick since its read-only after construction (thus no cache destruction).
The logger has many other slow-downs worth looking at, the number of cycles here should be low compared to those other issues.
There was a problem hiding this comment.
At least one log is called rom a static object ctor (crypto::null_skey -> mlock -> get_page_size), so efore starting threads.
"allowed" is still showing a bit on the profile, I suspect just the locking, but that's still acceptable now. getresetELPP was just > 2%, whch seemed outrageous.
There was a problem hiding this comment.
Relying on a static object to be constructed is problematic - the process could be linked without the crypto lib. Additionally, I hope to provide a patch that removes that log before main because it is impossible to disable logging to console (useful for the light wallet server admin process which can be used by python apps or bash scripts etc).
There was a problem hiding this comment.
BTW - this probably won't cause a problem, but I'm not sure how helpful the 2% in the profile is in this case - there are log statements everywhere so this function is going to get skewed due to all of those calls. How much on aggregate do some of these functions with log statements perform now? It should be a fairly small increase overall.
There was a problem hiding this comment.
I don't understand what you're asking.
There was a problem hiding this comment.
If you're asking "is it slow because it's called a lot", then yes.
This reverts commit 7f8bdeb.
Turns out getting the global shared_ptr hits the profile, and passing it around still keeps it at close to ~1% CPU, which is too much for mostly silent logging. Leak the object instead, which is even safer for late logging.
moneromooo-monero
force-pushed
the
fl
branch
from
1122170 to
721aacd
Compare
If someone has a better patch, feel free.