Scrolling speed of the index can be improved

There is a difference in trade off between the two version in how much data is kept in memory. The perl version keeps all data in memory while the python requests it on the fly.

I found that the python version performs especially worse for large namespaces (so many notes without much hierarchy) and I have implemented some optimizations for that in the development tree since releasing 0.46. If you want to try this out, you can fetch the development branch with "bzr branch lp:zim".

How many notes do you approximately have in the top level of the notebook ?

Ah, excellent, the development version is a big improvement. It's still slightly slower than the Perl version though. (Laggy scrolling when using the wheel, as opposed to using the scrollbar, seems to be a general issue in GTK+. I just noticed similar problems with the GtkTreeStore demo in gtk-demo.)

I have 158 pages and 13 folders at the top level.

On Tue, May 4, 2010 at 8:31 PM, Henrik <email address hidden> wrote:
> Ah, excellent, the development version is a big improvement. It's still
> slightly slower than the Perl version though. (Laggy scrolling when
> using the wheel, as opposed to using the scrollbar, seems to be a
> general issue in GTK+. I just noticed similar problems with the
> GtkTreeStore demo in gtk-demo.)
>
> I have 158 pages and 13 folders at the top level.

Hmm, that is not nearly as much as I would have expected to cause problems.

Do you feel performance is acceptable with the development version
from a usability point of view, or is further optimization needed ?

-- Jaap

The development version is usable, but further optimization would be nice.

It feels like the page content is faster to scroll, even with several hundred lines of text, links, headings, etc. So it should theoretically be possible to get the same performance for a simple list, right? :)

Yes, if we load the whole index in memory it would scroll just as fast as the page. Problem is we can not predict up front what pages are visible in the treeview, since this is queried incremental. (Especially when multiple levels are expanded in the treeview, we can't be sure which will be needed during a scroll action.) Tried to make a reasonable caching that scales with respect to memory usage with reasonable speed. But admitted it may be not the best trade off for relative small notebooks.

Probably will need to investigate further refinement of caching algorithm. Maybe have the gui give feedback about the state of the visible treeview to the cache.

One way for improvement is to have the index contain hints on what levels are expanded and adjust caching accordingly. This could be achieved by fixing bug #269042.

Closing this report for now as a "Won't Fix" as I don't think we will further improve scrolling speed any time soon. Tested on some low spec systems and behavior seems reasonable.