I used to find the performance of LVP to be fine, but now it is unusable. It takes from 30s to several minutes to display a 145KB log entry, and uses 25-30% CPU during this time. This is with a single 500MB file open and no searches or highlights. Searching in the file also takes more than 30s.

I am using version 3.0.16.

I suspect it may have to do with the size of individual log entries. Some contain XML payloads as large as 3MB. When one of these is displayed, even selecting text is noticeably slow.

Thanks for reporting this issue.

What kind of machine are you using to run LogViewPlus?  Does it have enough memory for the number of log files being accessed?  If a log file has been rolled, the Windows reported file size may not accurately reflect the size of the log entries in memory.

We performance test LogViewPlus regularly.  I will be sure to do extra performance testing before the next release to see where we can improve.  Are these performance problems application wide, or is there a specific area where you would like us to focus our testing?

The XML display issues are likely due to syntax highlighting.  You can disable syntax highlighting to improve performance.

You can find out more about the LogViewPlus Performance Profile in our documentation.

Thanks again,

Toby

Hi, thanks for your reply.

The machine has 28GB of memory of which 15.5GB are available.

The issue seems to be mostly when loading a log entry, but this happens also when switching views, so it makes that very slow too. When hitting Ctrl+F, the find dialog also takes several seconds to appear.

I have just now disabled syntax highlighting and it seems to have made a huge difference.

That's very helpful thanks.  

It sounds like the problem is mostly with syntax highlighting.  The Ctrl+F is likely slow because the application is busy with other tasks as there is really very little processing needed to display that form.  I will focus our performance testing efforts on syntax highlighting and see what we can do.

FYI, we also had another support issue today related to syntax highlighting performance.  In that ticket, the user is trying to load a 100MB log entry - which we really shouldn't even attempt to highlight.  The next version of LogViewPlus will likely have some cut-off threshold above which syntax highlighting will be disabled by default.

Thanks, that sounds like a good solution.

Even after disabling syntax highlighting, it still takes 27s to open a 3MB log entry. For comparison, when I use "Open in Text Editor" to open the entry in Notepad++, it takes less than 3s.

Aside from the slowness, it's not great that while loading an entry, the whole application is frozen and there is no progress indication. It would be nice if it could load the entry in the background while keeping the UI responsive, ideally with a way to cancel the load if it's taking too long. Having a progress indicator so you have some idea how long you will have to wait would also help.

Just a quick note to let you know that we have now released LogViewPlus v3.0.24 as a BETA release.

This release addresses the "large text / performance" issue discussed above.  This is discussed in detail on the other thread, but the short version is that we will limit the displayed text to 50 KB by default and give the user the ability to either Override that behaviour or Open in Text Editor:



Limiting the text size will help with the application responsiveness issue you highlighted above.

Hope that helps,

Toby

Thanks for the update, but I think part of the problem is not related to large messages. I often find that opening dialogs takes many seconds. In the meantime it just displays a white box where the dialog should be:

When opening the find box, sometimes I am able to paste in some text and hit enter to close it before the dialog ever displays, but most of the time I just have to wait.

Given the amount of memory your machine has, I would guess there is a performance issue which is tying up the GUI thread.  One thing to try is switching to DirectX rendering.  

Aside from that, it would help if we could focus our performance testing.  Is there anything unusual you might be doing which is contributing to this issue?  Have you noticed any sudden degradation after using a particular feature?  You could also try turning features off in settings to see if that helps identify the problem area.