Version: 1.4 (using KDE 3.3.2, Gentoo) Compiler: gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) OS: Linux (i686) release 2.6.9-gentoo-r9 Problem description =================== Performing a "Find in History", "Find Previous", or "Find Next" within a Konsole instance that is configured with: Setting > History... > Number of lines = Unlimited can lock that Konsole instance, and peg your CPU at 100% usage for very long period of time. [This requires that your search string doesn't exist in Konsole's history, and that you have a *very* large history.] If possible, can a "Cancel search", "Cancel find", or "Cancel operation" button be added? To replicate the problem ======================== [This was tested on a PIII 866 with 512MB of RAM.] Launch a new Konsole Set your History to 500,000 lines. $ su - root $ cd /var/log $ while true; do for fn in `find . | grep \.log$`; do \ echo ${fn}; cat ${fn}; done; done Scroll up to the top of your history and hang out there until text begins to scroll by. Hit Ctrl-C. Your Konsole history is now full. Now perform a: Edit > Find in History... Find = "slkdfjlsdjflskdfjl" Find backwards = checked Then hit "Find".
I followed your example and it works fine here using CVS/3.4.0beta2. The CPU pegs 100% for about 4 secs and then the 'not found' dialog popups. I see we are both running Gentoo systems... something must be different... Kernel: 2.6.10 Compiled: Dec 29 15:38:10 EST 2004 Machine: i686 AMD Duron(tm) clocked at 1300.668 mHz 2564.09 Bogomips 743248kB RAM gcc-3.3.4 glibc-2.3.4.20040808-r1
Created attachment 9727 [details] Screen shot of how this is handled in the Gimp 2.0
Created attachment 9728 [details] Timelapse screen shot of how the Gimp 2.0 handles this. Timelapse screen shot of how the Gimp 2.0 handles this (you can see the progress bar has grown since the last screenshot).
Comment #2-#3: wrong bug report?!?
Oops, those attachments overwrote my response to Kurt. Here it is again: Hey Kurt - my replication instructions were not as clear as they should have been. My intent was to demonstrate the Konsole locking up for a few seconds, and pegging the CPU at 100% during that time. Konsole always *does* come back with the "not found" message, but in the mean time it leaves the user wondering what has happened. To appreciate this, one would have to have a history of many million lines, and then do a search for a non-existent string. In my case, I have had: - history set to "unlimited" - a *huge* history - and a search string containing a typo (therefore an unfindable search string) Yesterday I had Konsole go away for 15 minutes on a P4 2.5GHz, 1GB RAM. That was somewhat uncomfortable as I did it on my organizations build server :/. Oops :).
So you really want a progress bar and a Cancel button on the find dialog, correct? Konsole/Kate/Konq all use the same find dialog...
IIRC "Find in History" is implemented very "simple" - it should be possible to optimize/speed it up.
Yes, a progress bar would be nice, but at least making a Cancel button available (after the find has begun) would improve the user experience.
Created attachment 9747 [details] Clearly labelled screen shot of the Gimp's progress bar + cancel button This is a screen shot of the Gimp during a potentially CPU-intensive + long duration operation (a Gaussian blur). It is really clear what progress is being made on the operation, and it is possible to cancel the operation if the user so desires.
Created attachment 9748 [details] A second screen shot, a few seconds later, showing progress bar growth. This screen shot is the same as the previous, excpet it is taken a few moments after the first (and therefore the progress bar has grown).
You should better send a patch than bombarding us with screenshots.
This needs fixed in kdelibs. If you try other KDE apps, you'll see the same find dialog. There also appears to be a number of find/dialog in kdelibs... cleanup for KDE4?
SVN commit #569751 goes some way towards alleviating the problem by improving search performance. A progress dialog would still be useful when dealing with a multi-million line history though.
Konsole's scrollback search is much faster in KDE 4 which helps matters somewhat. If you need to search a very large history it would be much better to save the output and use existing tools such as grep which offer more powerful and efficient search tools.