Add a cache for pinned statistics

[jgkamat]

Combined with config caching, I think this should raise the amount of usable tabs to about ~100.

This is a little more complicated than @The-Compiler s initial patch, but I think it should be a little better this way (as it only clears the pinned statistic cache when needed). A cleaner way of doing this is keeping track of the pinned width as the tabs change (by adding and removing sizes) rather than iterating over them every time. However, I think this is more than enough to fix it from being a bottleneck with lots of tabs.

This helps out with #4069, but only for extreme amounts of tabs (~100), wheras config caching would help everything. I think this patch is the one that helps the most with deleting the first tab (which is the described issue in #4069) as well.

---

This change is 

[qutebrowser-bot]

Thanks for the pull request! Note that reviews currently can take a bit longer, as @The-Compiler is busy with exams until September.

(Powered by GitMate.io)

[The-Compiler]

Can't you just do:

if tab.data.pinned == pinned:
    return

here? No need to call set_tab_data and set tab.data.pinned if it's already the same value either, right?

[The-Compiler]

I don't see a substantiated reason to override pylint here - I can see two solutions:

• Make _pinned_statistics public (even if it's not called as a function from the outside). This seems fair, because we can't look at TabBar in isolation anymore when changing something about pinned_statistics.
• Probably preferrable: Add a clear_pinned_statistics signal to TabWidget, and hook that up to self._pinned_statistics.cache_clear in TabBar.

[The-Compiler]

Nitpick: Use the same order (before/after _minimum_tab_size_hint_helper.cache_clear) like below - doesn't matter which one 😉

[jgkamat]

I really don't like how sensitive this is to the exact order things are done in, so I would like to find a better way to invalidate the cache if possible. One way that I thought of is that we can keep a count of tabs independent from the QTabBar, and when they differ invalidate the cache (in tabSizeHint). This has the advantage of being able to more 'correctly' handle additions/removals if the tabs are resized (which they should be, by qt), but if a new tab is added before the redraw there can be problems.

In order to prevent a crash when this happens I clamped the division by zero below, not a great solution, but I'd much rather have mis-sized tabs than a crash if we mess up this logic.

I thought about this a bit and we might not actually need any of this (unless I forgot a feature with tab sizing). I'll submit a PR and hopefully we can discard this one...