"Andreas Nicolai" <Andreas.Nicolai@gmx.net> wrote 09.10.2007 15:43:55:
< snip: It takes 3 mins to display KDE full log >
> Here we probably need something like a data-view model to speed this up.
> Placing always all data in the grid will make it naturally slow.
> only the relevant data, meaning the data that is actually shown should
> requested. Sorting indices could be created once the data was read and
> instead of resorting all data in the grid, it could just use a different
> sorting index and update the current view.
> Problem is: can this be done with the current GUI classes? Or does this
> require a partial rewrite of the grid? Essentially what's needed by the
> data model is:
> - return (quickly) the data for a given range of rows (first and last
> visible row) and sort index
> - return total number of rows
> The view would have to be a fairly simple grid - without a vertical
> scrollbar, though. Because the grid itself will only contain the actual
> visible data, so the about 30 lines or so that fit into the grid. The
> vertical scrollbar must be a separate window control.
Yes, the current UI controls support that "browse grid" functionality.
But the infrastructure to feed the grid efficiently will require some
implementation effort. I already made up my mind on how to do it.
My plan is to this in 1.6. A full diplay should be possible in less
than 1 second after loading the data from disk. A non-pattern string
filter can be applied in that time as well.
If I find enough time and all turns out well, we may get instantaneous
log / statistics / rev graphs / merge info for repositories of any
practical size. The basic idea is to have TSVNCache extended to poll
(optionally!) the repository. Once the disk I/O bottleneck is lifted
OpenMP will give you any amount of performance you may ask and pay for.
> The model could be written fairly quickly, but the view code... :-(
The data model is already there (log cache) and much faster
than anticipated: the log for *any* path is found at 10M
revisions per second (total revisions in cache).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Oct 16 14:34:21 2007