Bug 253314

Summary: Konsole performance: programs that print a lot of text on stdout/stderr slow down a lot
Product: [Applications] konsole Reporter: Yuri <yuri>
Component: generalAssignee: Konsole Developer <konsole-devel>
Status: RESOLVED DUPLICATE    
Severity: normal CC: adaptee, robertknight
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: FreeBSD Ports   
OS: FreeBSD   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Yuri 2010-10-05 15:06:33 UTC 
Version:           unspecified (using KDE 4.4.5) 
OS:                FreeBSD

When I work in terminal I often run something that prints a lot of text. Konsole apparently attempts to display every single line for a quick few milliseconds. As a result lines aren't readable and slow down is introduced.

Desired behavior: konsole should detect that there is more text printed than it can display with normal timing. In such condition konsole should be skipping through text, only displaying some randomly selected fragments for some intervals of time that would allow human to perceive them to some extent. Make such interval user-configurable. Also it would be nice to have some idea how many lines were printed, so konsole can display, for example, 150000 lines/sec in the corner when the speed is very high.

For example, this slowdown was caused by konsole: user=20152ms sys=403ms wall=73273ms

Of course, there is always a workaround of just directing the output into file. But my suggestion makes konsole itself more graceful and nicer to user.

Reproducible: Didn't try
Comment 1 Robert Knight 2010-10-07 00:53:34 UTC 
Konsole already does what you describe.  Repeated updates are buffered and only sent to the screen at periodic intervals.  However, there is still a cost to updating the screen periodically and processing all the changes received from the terminal.

> For example, this slowdown was caused by konsole: user=20152ms
> sys=403ms wall=73273ms

That doesn't tell us much.  If you have a benchmark you need to provide instructions sothat other people can follow to reproduce it.

> Of course, there is always a workaround of just directing 
> the output into file.

That is not just a 'workaround', it is the right thing to do.  If you actually care about what is output to the screen and what to search it, filter it or do some other analysis of it then that is a lot easier if the content is written to a file.
Comment 2 Yuri 2010-10-07 00:56:43 UTC 
This means that this functionality isn't working properly. If it still takes too much CPU to process screen updates you should automatically adjust an update rate.
Comment 3 Jekyll Wu 2011-07-31 13:20:07 UTC 

*** This bug has been marked as a duplicate of bug 230184 ***