Save your performance baseline
Here’s a one week old post I forgot to publish:
I did some performance testing and fixing in logview4net today, but I threw away the baseline performance report. I managed to shave some processing time, but I only kept the previous report so I am not certain how much I saved. It’s a stupid mistake but hopefully I’ll not make it again now that I’ve told you about it. Save your baseline for future comparison when doing performance optimizations.
Almost all processing time is spent on appending and sometimes formatting text to a RichTextBox. It is not as fast as I would like it to be. I could probably write something that does what I want myself, but I guess someone has already done that. All the functionality of the RichTextBox is not needed for logview4net. I only need to change the font and color properties of parts of the text. There are no editing, tables, bullets, images or anything else that I guess is complicated to do.
After some more communicating with a nice user it seems that the performance is mostly annoying when loading a large file. It is a scenario I didn’t build it for at all. It is build to show one message a time and hence has relatively much time to process it.
…anyway; A new release that works a little bit better in this scenario is on the way. I got the load time for this file down from more than one hour (I killed the process after that.) to less than 30 seconds.
Design decision for logview4net and a new release.
New year, new release.
This release incorporates the performance fixes that were maid last week after some user feedback.
I still have no intentions to turn logview4net into a full featured log parser, but now it can handle much bigger datasets than before. If I get some bright ideas it might get faster still. The problem is that I load all existing data into the textbox that shows the data. So if you add a file or SQL listener and there is lots of data already there and you choose to show it all; logview4net will treat each row as a separate message and show each message one at a time.
The design decision I’ve made for logview4net is that all listeners are treated as being forward only data. This means that I can’t get past time data from a listener, it will send new data to the part of the program I call the viewer. The viewer is essentially the textbox that shows all formatted data. This decision was made because I’d rather have lots of available datasources than a fast way to look at old data. logview4net was initially and primarily built to be a real time log viewer/monitor, not a log parser to use on historic data.
If I only worked with random access data I could take the same approach as Kiwi Log Viewer and load only the data that the use can see at the moment. I have some ideas on how to merge these worlds and I’ll probably use the blog to make them more tangible for myself.
The changes made to release 8.01 removed lots of processing time when receiving an event but the greediest part is the RichTextBox that comes with the .Net Framework so I’m looking for a replacement for that.
Performance issues in logview4net
I recently got a message from a user who had performance issues with logview4net when using the pause function in combination with lots of incoming events. Since pause is probably mostly used in situations when there are lots of events I guess more users than Bill and I have noticed it before. I have two cores on my main machine so I usually just let it be until logview4net has recovered by it self. The problem is that almost all processing of an event takes place when it is time to display it, not when it is received. When running in normal mode this is ok, but when coming back from pause mode this places a big burden on the display thread.
I’ve made a change today so that the application does all processing of an event, except the coloring, before it is sent to the cache when in pause mode. That way the processor utilization should be almost the same when in pause mode as when running normally.
I will make the new release in the first week of January to get the nice version number 8.01
