rev 11718 cuts the skip/save logging time in half

The time left is now mostly the time needed to resize the columns on the Logs tab; we do that each time an item is added or removed and it takes longer and longer as the number of items grows. Logically we only need to do that if an entry with the longest data in one of the columns has been added or removed, or perhaps if the Logs tabs doesn't have focus we could only refresh it when the user opens it. I'll investigate whether we can be smarter about the column resizing to improve the performance further.

I guess I jumped the gun on asking for this process to be threaded (not having looked at the code). If performance can be tweaked without doing that, all the better.

As for refreshing the logs tabs, that makes perfect sense that they wouldn't be refreshed unless they were currently open, or being opened. Otherwise, who is the refresh benefiting? All it's doing is dragging down the list processing.

In T116959#1765237, @Stevietheman wrote:

I guess I jumped the gun on asking for this process to be threaded (not having looked at the code). If performance can be tweaked without doing that, all the better.

Probably should be done anyway, but be filed as a separate task

rev 11722 Further cut logging time nearly in half: cache size of logging list column heading widths to avoid recalculating each time entry is added

rev 11723 Further cut logging time (by a third to a half), avoid resizing columns with fixed-width content