Source: WowAce

Hey everyone , past few weeks had fps drop/freeze when was mouseover rarity icon or when it's loading when you log in, couldn't fix it unless was completely reinstalling it and losing all data(which sucks) but today by mistake clicked rarity icon and changed "sorted by" and all freezes gone, started testing stuff looks like sorting by anything but name making freezes/fps drops(sort by zone most busted just 2-3 freeze).
posting here because maybe anyone had similar issue and devs might can fix it.

Mostly resolved as of #409. The remaining performance issues will be tackled individually, based on the sort method.

Looks like LibQTip is the main culprit of slow tooltip rendering times, while sorting has a negligible impact on my system. It's still unclear why changing the sort mode affects the time negatively, perhaps both issues influence each other somehow. I've disabled sorting to basically no effect, so I'm now trying to first eliminate the LibQTip delay, if I can.

I'll investigate the sorting afterwards to see where that leads.

As is evident from this benchmark, the two most basic sort methods are "only" kind of slow. The two intermediate ones are far too slow for a good user experience, even on my desktop PC. And sorting by zone is absolutely unacceptable, considering this is with a very limited number of items being displayed.

Someone who just started out collecting will basically be sitting there for half a minute if they picked this sort method, and likely some seconds at least if they picked the "fast" ones. This will be far worse if someone uses slower hardware or added many custom items, but let's not get into that now.

The good news is that we have clearly identified two isolated issues to tackle here, and we can benchmark performance effectively (well, sort of, anyway) with some profiling code I wrote, so it should be possible to optimize this until times seem acceptable. What that means will obviously still have to be established, though I think a maximum combined sorting and rendering time of 250 to 400ms should be a good first goal. This would be faster than the current "best case" scenario, which is still usable.

Since this will require dedicated testing and targeted improvements for each sort method, as well properly dealing with the long-standing LibQTip issues that clearly mandate a different approach in the rendering routines (e.g., caching and updating on a line basis instead of rebuilding the entire tooltip...), I'm splitting this into separate issues.

No sorting (replaced with NOOP):

Sorting by name:

Sorting by category, then name:

Sorting by difficulty:

Sorting by percent complete:

Sorting by zone:

Another report of this suggests there might be a problem with the sorting algorithms used: https://www.wowace.com/projects/rarity/issues/480

Since we've since refactored the Core and they're self-contained in the Sorting module, it should now be easier to benchmark and ideally improve the sorting times, even for large numbers of items (to future proof against Blizzard's collection madness, and to make sure the sorting is fast even on low-end computers).

In fact, we should probably set a fixed limit for X items, and make sure it's always kept, to guard against regressions and using automated tests (might require a separate issue).

Bumping this up in priority, as it now seems easy enough to tackle and it might account for a large number of the issues people have with Rarity's loading time (alongside LibQTip being slow, see #136 and #120).