getting-things-gnome
Remember and activate the sidebar's last viewed tag filter on startup
Considering how @jaesivsm's optimization to process tasks only for the currently used tab (Open vs Actionable vs Closed) has pretty much cut startup time roughly in half (question: does the code explicitly restore only the last used tab view on startup, without processing the whole tree, or does it still somehow do the work "at least twice instead of thrice"?)... some crazy thought just occurred to me, not only as a usability enhancement, but also as a crazy startup performance hack: on startup, when initially determining which tasks to show/process, GTG should not only restore the state of "which tab is selected", but also the state of "which tag was selected in the sidebar" (if any), and filter to that.
Taking my own data as an example, even my most populous tag only encompasses a third of my tasks, and most tags encompass 1/10th or even 1/20th of the total tasks... so you would get the compounding effect of "2x faster startup from showing only actionable tasks, multiplied by 3-20x faster startup from showing only those for the selected tag".
If that actually works, that'd be a crazy cheap and effective optimization hack for most cases. Of course this is a dirty, dirty hack sweeping the problem under the rug and this doesn't eliminate the need to truly make the software faster at processing task trees (issue #109), but it I see no reason not to do it as it would be an extra performance boost that compounds on top of those future optimizations, so when we eventually solve 109 we might get near-instantaneous startup ;)
question: does the code explicitly restore only the last used tab view on startup, without processing the whole tree, or does it still somehow do the work "at least twice instead of thrice"?
Yes, all iteration on all panes have been removed and the current MainWindow.reapply_filter() method call only leads to one FilteredTree.refilter().
GTG should not only restore the state of "which tab is selected", but also the state of "which tag was selected in the sidebar" (if any), and filter to that.
From what I understand, when applying a FilteredTree.refilter() the tree is browsed in all ways a lot of times, regardless of the node branches being displayed or not. The real culprit of the slowness being the callbacks emitting signals to the Gtk layer, my guesstimation, for a first draw, would be that pre-selecting a tag wouldn't change exec time much. But I'm really not sure and it might be worth a try.
But the feature in itself would be nice :)
