Ich verwende Boost-Log und den globalen Schweregrad Logger für die Logging-Plattform meiner Anwendung.
Profiling zeigt, dass die boost::log::v2s_mt_posix::core::open_record aufnehmen kann
25% der gesamten Ausführungszeit.
Ich habe viele Log-Nachrichten, aber ich würde nicht erwarten, dass sie so teuer sind, wie sie es sind niedrigerer Schweregrad und sie werden gefiltert .
Gibt es eine Möglichkeit, diese Nachrichten in der Laufzeit nicht so kostspielig zu machen? (wiederum: Ich erwarte einen kleinen Overhead, selbst wenn gefiltert und natürlich ein größerer, wenn nicht gefiltert).
Die Kompilierzeit ist relativ einfach zu "reparieren", indem einige Wrapper-Makros erstellt werden.
AKTUALISIERT mit Beispielcode:
%Vor% Das Ausführen mit dem Argument 0 gibt keine Protokollnachrichten aus, aber es dauert zweimal (!)
Zeit, als die LOG-Nachricht auskommentieren.
Bei der Protokollierung muss oft protokolliert werden, was protokolliert wird, und diese Auswertung erfolgt vor der eigentlichen Entscheidung, ob protokolliert werden soll oder nicht. Zum Beispiel:
%Vor% Wir hatten ein selbst entwickeltes Logging-System, das dem Protokoll die aktuelle Zeit hinzufügte, was ein Aufruf von gettimeofday() war. Es stellte sich heraus, dass 20% der CPU-Auslastung im Programm Aufrufe in gettimeofday() für Protokollfunktionen waren, die nie irgendwo hingelangen.
Eine Problemumgehung (dies ist eine Marmite-Lösung, btw.) besteht darin, ein Makro zum Umbrechen der Protokollierung zu verwenden, zum Beispiel:
%Vor%Dann:
%Vor% Sie können sicher sein, dass someExpensiveFunction() nur auf einer Ebene ausgeführt wird, die INFO unterstützt.
Verdammt, du könntest sogar so weit gehen, es komplett zu kompilieren,
%Vor%Ein weiterer Vorteil wäre, dass Sie die Protokollierungsimplementierung ändern könnten, indem Sie das Makro ändern und nicht Ihren gesamten Code überall ändern.