Re: Speed improvement of gnome-terminal

["DmD (Spider) Ljungmark" <spider takeit se>]

On Fri, 2004-10-15 at 01:00 +0100, Alan Cox wrote:
> On Iau, 2004-10-14 at 15:47, Owen Taylor wrote:
> > One thing you can think about is - what is the correct behavior when
> > catting a large text file to a terminal - shouldn't it just show the
> > last page instantly?
> 
> The data doesn't arrive instantly however. The simple model is to handle
> refreshes under full load in terms of a desired "frames per second"



spider Darkmere ~ $ du -b log3
12612468        log3
spider Darkmere ~ $ time gnome-terminal -e "cat log3"

real    0m0.138s
user    0m0.017s
sys     0m0.008s


hmm.. thats fast. thats really fast.  But check again, if I use a
stopwatch to actually time the appearance on screen, and disappearance,
its completely different.

in average it is around ~8  seconds.  All of that time is spent inside
X, after the "time" has said its done.

Lets see with xterm then:

spider Darkmere ~ $ time xterm -e "cat log3"

real    0m9.002s
user    0m7.171s
sys     0m0.574s

hmm. strange, about the same, but thats without antialiasing, so lets
get antialiasing running : 

spider Darkmere ~ $ time xterm -fa 'Monospace' -fs 10 -e "cat log3"

real    4m21.778s
user    0m9.077s
sys     0m0.590s

Erm.. ouch.

hmm.. what about aterm, with my default config (ohh, transparent
background)

spider Darkmere ~ $ time aterm -e "cat log3"

real    0m0.140s
user    0m0.053s
sys     0m0.010s

Yep.  thats how long it takes.  Magic?  but without AA, and it doesn't
support AA :-(


Well, I could start up oprofile and get some more output on the
gnome-terminal issues if you really want to see where the bottlenecks
are, however, most of it will probably be spent inside a certain
companys crappy binary-only graphics-drivers, not much to see there :-/




//Spider