View Revisions: Issue #3089

Summary 0003089: "Monitor" pane in Logbook uses lots of CPU
Revision 2019-02-02 23:12 by WA9PIE
Description The "Monitor" is intended to show diagnostic information from the application. It has largely the same intent as the "Logfile" tab, some differences in its implementation:


  • It uses a Rich Edit control rather than a List Control. The rich edit control is substantially more expensive for CPU usage and memory consumption

  • It shows all trace information; it is not filtered like the Logfile tab.



The use of a rich edit control for logging is not a good design. The control limits itself to displaying about 16K of data. When a new string is added to the control, the length of the data in the control is checked. If it is more than 16K, data is removed from the beginning of the control, one line at a time, until the length is less than 16K. Then, the new data is added.

While the control isn't used by most users, the code to drive it is always active. Any message logged by the application -- debug trace, regular trace, timing trace -- is always added to the control and the control's content pruned each time, even when the window isn't visible. The management of the control can take a tremendous amount of CPU and memory. When the control is visible, it updates and repaints constantly. For each string added to it, it will redraw for the added string, but also redraw once for each string remove in order to replace the added string.

Because the window has a drastic negative effect on the product and is a subset of the functionality offered by the Logfile tab, we should remove it.


Revision 2019-01-23 12:47 by K7ZCZ
Description
The "Monitor" is intended to show diagnostic information from the application. It has largely the same intent as the "Logfile" tab, some differences in its implementation:


  • It uses a Rich Edit control rather than a List Control. The rich edit control is substantially more expensive for CPU usage and memory consumption

  • It shows all trace information; it is not filtered like the Logfile tab.



The use of a rich edit control for logging is not a good design. The control limits itself to displaying about 16K of data. When a new string is added to the control, the length of the data in the control is checked. If it is more than 16K, data is removed from the beginning of the control, one line at a time, until the length is less than 16K. Then, the new data is added.

While the control isn't used by most users, the code to drive it is always active. Any message logged by the application -- debug trace, regular trace, timing trace -- is always added to the control and the control's content pruned each time, even when the window isn't visible. The management of the control can take a tremendous amount of CPU and memory. When the control is visible, it updates and repaints constantly. For each string added to it, it will redraw for the added string, but also redraw once for each string remove in order to replace the added string.

Because the window has a drastic negative effect on the product and is a subset of the functionality offered by the Logfile tab, we should remove it.