Bug 253314 - Konsole performance: programs that print a lot of text on stdout/stderr slow down a lot
Summary: Konsole performance: programs that print a lot of text on stdout/stderr slow ...
Status: RESOLVED DUPLICATE of bug 230184
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: FreeBSD Ports FreeBSD
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-05 15:06 UTC by Yuri
Modified: 2011-07-31 13:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 ***