After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 370930 - search can be awfully long on version 0.118
search can be awfully long on version 0.118
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other Linux
: Normal minor
: 1.0
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2006-11-05 09:38 UTC by vincent dupaquis
Modified: 2006-11-10 05:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0.118 patch (6.40 KB, patch)
2006-11-06 07:00 UTC, Charles Kerr
none Details | Review
slightly cleaner revision of earlier patch. (6.52 KB, patch)
2006-11-06 20:36 UTC, Charles Kerr
none Details | Review
fix bug in earlier patch (6.04 KB, patch)
2006-11-06 21:32 UTC, Charles Kerr
none Details | Review
more speedups. :) (3.09 KB, patch)
2006-11-10 05:10 UTC, Charles Kerr
none Details | Review

Description vincent dupaquis 2006-11-05 09:38:00 UTC
Hello,

When downloading all articles from alt.binaries.boneless, and trying to make a filter on few of them (it should at the end select a few tenths of them), it takes ages to complete.

This NG is huge, but would it be possible that from a given size (for instance > 10000 articles), the filter is only performed when "enter" is hit, and not only when a caracter is typed ?

Else, it is impossible to do any search on these kinds of NG and PAN stays stuck and consumes all CPU.

For me, handling HUGE NG is a mandatory feature and is the one which makes the difference between a good NG tool and bad ones.

Last, a good example of handling of HUGE NG is Klibido.

Regards,
Vincent.

PS : My configuration is Suse 10.1, on Gnome (2.12.xxx), Kernel is 32bits on a x86_64. 1Gb of RAM.
Comment 1 Charles Kerr 2006-11-06 05:43:33 UTC
This is coming from a surprise source: according to sysprof, the overwhelming
part of Pan's time in filtering comes from HeaderPane::on_tree_change() where
it's erasing Row pointers from _mid_to_row.

Both _mid_to_row and diffs.removed are sorted by Quark, so it should be
pretty trivial to implement a set_difference (_mid_to_row, diffs.removed)
into a temporary and then call _mid_to_row.swap (temporary).

I'm kind of surprised at this wart, thanks for reporting it Vincent.
Comment 2 Charles Kerr 2006-11-06 07:00:38 UTC
Created attachment 76068 [details] [review]
0.118 patch

filtering speedups.  testers wanted.
Comment 3 Charles Kerr 2006-11-06 20:36:08 UTC
Created attachment 76110 [details] [review]
slightly cleaner revision of earlier patch.
Comment 4 Charles Kerr 2006-11-06 21:32:10 UTC
Created attachment 76114 [details] [review]
fix bug in earlier patch

Fixed a bug in the header pane changes.  0.118 is an N-pass where N
is number of rows to be removed during filtering... previous patch
was 1-pass but convoluted... new patch is 2-pass but much easier to
read and, hopefully, maintain.
Comment 5 vincent dupaquis 2006-11-09 21:19:57 UTC
Hello,

After testing, it seems that despite being much faster than before, a simple search of a 4 characters string took something like ~1 minute on my AMD64.
Would it be possible some supplemental improvements are possible ?

Anyway, congratulation for the reaction time !

Regards,
   Vincent.
Comment 6 Charles Kerr 2006-11-10 05:10:52 UTC
Created attachment 76315 [details] [review]
more speedups. :)

If at first you don't succeed....
Comment 7 vincent dupaquis 2006-11-10 05:55:33 UTC
Seems better ;-)

One thing which is confusing is that because the cursor does not change its aspect, it is difficult to (at first sight) between an ended unsucessfull search and a long search amongst a huge group.

Next step is to download a 9Gb dvd image ;-)