On Fri, Mar 12, 2010 at 04:33:39PM -0800, Elliott Mitchell <e...@m5p.com> was heard to say: > Updating the display of packages behind the search box while typing > characters is nice, it is also rather sluggish. Worse, it appears that > aptitude updates its display after each character pressed, not accounting > for someone having typed faster and being several characters ahead of the > update. This is sufficiently bad such that doing searches on an ARM > machine is *painful*. > > #317841 also hits this machine hard. What is happening, doing a linear > search of every single package name???
Actually, it's a linear search over the displayed list of packages, which is similar but not identical. This used to work fine; over time the package list has expanded and people have started trying to run aptitude on wristwatch architectures. The solution is probably a combination of optimizing search (i.e., using indexes more aggressively), changing the curses UI so it actually benefits from the optimizations, and running searches in a background thread the way the GTK+ UI does. Not very high on my priority list, though: on the slowest machine I own (an early Asus EEE netbook), I can fully load the processor with compile jobs *and* have aptitude itself resolving dependencies in a background thread, and the lag is only noticable the first time I type a character that forces it to scan the whole list. And for that one that I only counted about two seconds at most. Earlier characters were fine, later characters were fine; it was just the one that caused my match to fail that was slow. It's a problem, just not one that seems to impact most modern machines much. By the way, a good workaround is to just use "l" for most searching tasks, particularly on large lists. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
