"proofs" about Konsole

[karl.vogel at seagha.com]

Lubos Lunak <l.lunak at suse.cz> writes:

> BTW, "yes, we have a LOT of optimization possibilities ahead of us" - care to 
> list some that'd make a noticeable difference and wouldn't involve such 
> insanities like switching to plain C or, heaven forbid, assembler? I may be a 
> bit pessimistic, but I can hardly see more than a handful of SANE 
> optimization possibilities.

You asked for it :-)

I'm one of those cli-in-X (not that I'm complaining about bloat)

At work I have an old linux machine with KDE and I mostly use a couple of
Konsole's over an XDM login from my windows machine.

Works quite well.. memory is not an issue, neither is startup time (3 seconds
per Konsole).. as my sessions run for weeks without stopping (only time I 
close the sessions is because my windows box needs the zillionth reboot 
because of an update).

Anyway.. since I use this alot, I did have a look at improving things. The
XIM stuff in QT takes the better part of a second on my P2-400, doing a
"touch ~/.XCompose" improves startup by 1 second. (found this one on your
performance tips page :) )

Another thing I noticed by using my slow machine, is that sometimes the
scrolling becomes very slow, usually happens when some garbage is output
to the terminal.. closing the TAB and reopening it solves it. It is
very noticeable over the remote X connection.. I'm still not quite sure
what the exact problem is. (Clear/Reset Terminal don't help, changing
the font does... so I wonder if it's a freetype problem) 

Lastly.. Konsole isn't very network friendly.. scrolling the display
causes a repaint of the entire contents instead of scrolling the view
as rxvt/xterm do, since my X session is over Fast Ethernet, it's not
really a problem.. but for WAN/modem/ADSL setups (ie. with NX server),
I guess it's wasteful. (I'm aware that Konsole has 2 timers running
to prevent too frequent updates).