Opening the highlight manager took 1 minute and 10 seconds to display anything. After that it was nice and responsive. Currently I have 13 highlights and 20 searches open. I currently have 4-5 512MB files merged. I am not sure if it makes a difference how much I have open but I have the impression it is a bit faster but still very slow when there is only 1 small file open.

Thanks for the update.

Parsing does not occur on the main UI thread, so I don't think that is the issue.  5 GB of logs would significant.  How many searches are we talking about?  You should be able to determine this by looking at the highlight manager.    Also, do you notice any difference when you have fewer files open or fewer searches?

I don't think I am doing anything unusual other than using a custom PatternParser and setting the lookup strategy to Find all matches. I tend to have 1-10 512MB files open with several searches per file.

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.

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.

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

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.

Thanks, that sounds like a good solution.

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.

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.