dact very unresponsive if Sentences widget is used and there are many hits

[gertjanvannoord]

if you use the Sentence tab, and there are many hits (from 10 thousand to 100 thousand), Dact becomes more and more unresponsive, up to unusable.

If finally all hits are found, and you click on a single file, for instance in the Keyword in context mode, it takes 15 seconds to highlight that line.

Double-clicking on a line (in order to see the tree of that line) takes very long as well.

Going back to the sentences-tab then takes a minute.

[danieldk]

The primary cause of slowdowns is the fact that Qt needs to get size hints for every entry and since we are using proportional fonts, it needs to go through the font renderer. This can be observed by switching off 'Show Filenames' and using 'Complete Sentence' in the sentences tab. Dact will be more responsive, since we use a fixed width for the last column.

Summarized: Qt wasn't really made for such large list views with multiple columns.

There are three workarounds (I think):

1. Use lazy loading. But it gives quite a subpar experience (I used this in the mining viewer) and when you have scrolled through a substantial number of items, the same problems will surface.
2. Use resevoir sampling to maintain a sample of N sentences. This would work for very large corpora as well, but may upset users, since items can disappear as more results are found.
3. Introduce pagination.

[gertjanvannoord]

pagination might be the simplest? Users are used to such a presentation of many results.

would not be bad to do this for the Tree widget too - might make that widget a bit more reactive as well.

[danieldk]

On Oct 10, 2013, at 8:52 AM, gertjanvannoord wrote:
pagination might be the simplest? Users are used to such a presentation of many results.

would not be bad to do this for the Tree widget too - might make that widget a bit more reactive as well.

I think that I would like to try both pagination and sampling. I dislike pagination, but I don't know how annoying sampling will be ;).