Menu ▾ ▴

#656 Change the internal logging mechanism

v1.1.x
closed
Erik Hänel
internal (109) logging (1)
v1.1.4
Change Request
2022-03-10
2022-02-04
Erik Hänel
No

The internal logging mechanism is very deeply hardcoded and only accessible within the kernel. Change that to a global instance (which will gather information but only write them, once explicitly told to do so). The global instance might also be used for some imprecise profiling. Stripping down the log file might also be done, once the kernel tells the logger to do so.

Actually use and enable the timing with std::chrono implemented in the datetimetools.cpp file.

Analysis:

This requires an in-depth change of the position and organisation of the current logging logic. We well create a logger class with an internal buffer, where the logging information during start-up will be stored until the acutal information about whether a logging file might be saved, is set to this class. We will additionally think of introducing logging levels for more in-depth information.

Implementation:

  • Implementation: Implemented as proposed by the analysis.
  • Revision: [r1070]
  • Implementation test: Logs were created using different settings.

Documentation:

  • [x] ChangesLog updated
  • [x] Code changes commented
  • Documentation articles:
    • [ ] corresponding documentation articles updated
    • [ ] new documentation articles created
    • [x] not needed
  • Language files:
    • [ ] corresponding language files updated
    • [x] not needed

Tests:

The new logging mechanism was already used quite often to find and reduce performance bottlenecks.

Related

Commit: [r1070]

Discussion

  • Erik Hänel

    Erik Hänel - 2022-02-04
    • labels: --> internal, logging
    • status: open --> accepted
     

  • Erik Hänel

    Erik Hänel - 2022-02-04
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,3 +1,25 @@
 The internal logging mechanism is very deeply hardcoded and only accessible within the kernel. Change that to a global instance (which will gather information but only write them, once explicitly told to do so). The global instance might also be used for some imprecise profiling. Stripping down the log file might also be done, once the kernel tells the logger to do so.

 Actually use and enable the timing with `std::chrono` implemented in the datetimetools.cpp file.
+
+###Analysis:
+(*Describe, what's the issue and which changes have to be made*)
+
+###Implementation:
+* Implementation: (*Describe, what you've changed*) 
+* Revision: [rXXX]
+* Implementation test: (*Describe the type of test, which you performed, and if it was successful*)
+
+###Documentation:
+* [ ] ChangesLog updated
+* [ ] Code changes commented
+* **Documentation articles:**

+    * [ ] corresponding documentation articles updated
+    * [ ] new documentation articles created
+    * [ ] not needed
+* **Language files:**
+    * [ ] corresponding language files updated
+    * [ ] not needed
+
+###Tests:
+(*Describe, which tests you performed and their outcome*)
    • status: accepted --> analyzing
     

  • Erik Hänel

    Erik Hänel - 2022-02-04
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -3,7 +3,7 @@
 Actually use and enable the timing with `std::chrono` implemented in the datetimetools.cpp file.

 ###Analysis:
-(*Describe, what's the issue and which changes have to be made*)
+This requires an in-depth change of the position and organisation of the current logging logic. We well create a logger class with an internal buffer, where the logging information during start-up will be stored until the acutal information about  whether a logging file might be saved, is set to this class. We will additionally think of introducing logging levels for more in-depth information.

 ###Implementation:

 * Implementation: (*Describe, what you've changed*)
    • status: analyzing --> implementing
     

  • Erik Hänel

    Erik Hänel - 2022-02-13
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -6,20 +6,20 @@
 This requires an in-depth change of the position and organisation of the current logging logic. We well create a logger class with an internal buffer, where the logging information during start-up will be stored until the acutal information about  whether a logging file might be saved, is set to this class. We will additionally think of introducing logging levels for more in-depth information.

 ###Implementation:
-* Implementation: (*Describe, what you've changed*) 
-* Revision: [rXXX]
-* Implementation test: (*Describe the type of test, which you performed, and if it was successful*)
+* Implementation: Implemented as proposed by the analysis.
+* Revision: [r1070]
+* Implementation test: Logs were created using different settings.

 ###Documentation:
-* [ ] ChangesLog updated
-* [ ] Code changes commented
+* [x] ChangesLog updated
+* [x] Code changes commented

 * **Documentation articles:**
     * [ ] corresponding documentation articles updated
     * [ ] new documentation articles created
-    * [ ] not needed
+    * [x] not needed
 * **Language files:**
     * [ ] corresponding language files updated
-    * [ ] not needed
+    * [x] not needed

 ###Tests:
 (*Describe, which tests you performed and their outcome*)
    • status: implementing --> testing
     

    Related

    Commit: [r1070]

  • Erik Hänel

    Erik Hänel - 2022-03-10
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -22,4 +22,4 @@

     * [x] not needed

 ###Tests:
-(*Describe, which tests you performed and their outcome*)
+The new logging mechanism was already used quite often to find and reduce performance bottlenecks.
    • status: testing --> closed
     

Anonymous
Anonymous

Add attachments
Cancel