Compile times... Console versus Konsole

[retroman]

Hello all,

While the outcome should be obvious to all. I did a test today to see how drastic the time reduction can be if a particular package was emerged in a console rather than in a konsole in KDE. I never had a difinitive number to go by.

He was the test controls.

Package used: gaim Size : 5.979MB (downloaded before test into /usr/portage/distfiles)
Not emerged as an upgrade, on both tests there was no older gaim to remove, same version

TEST1-(usual computer setup): KDE, XORG, kbluetoothd, kweather, Karamba [1 applet running] , klipper, ksched.

System services:
Runlevel: default
local [ started ]
netmount [ started ]
bootsplash [ started ]
xdm [ started ]
hpoj [ started ]
sshd [ started ]
cupsd [ started ]
vmware [ stopped ]
autofs [ stopped ]
bluetooth [ started ]
alsasound [ started ]
xinetd [ started ]

TEST2-(minimal)

TTY console
System services:
Runlevel: default
local [ started ]
netmount [ started ]
bootsplash [ started ]
autofs [ stopped ]
xinetd [ started ]

Results with 'time emerge gaim'

TEST1: 6M 12.566S
TEST2: 4M 46.675S

That makes an emerge from the console in this test roughly 23% faster than in my normal operating mode.

I wonder what procentage of people do an emerge --update --deep world from kde vice the console??


Jordan

[Corona688]

I do know that a plain xterm has a "-j" option to let it scroll more than one line at once, which speeds up rapidly scrolling text significantly for emerges. What this option would be for konsole, if any, I can't say. In the end a hardware console is just so much less work on everything; instead of each character taking up 800 bytes of video memory, each character takes up one byte of video memory...

Unless you're using a framebuffer console or something silly like that. Then it's even slower.

[justbrowsing]

Hi,

instead of each character taking up 800 bytes of video memory, each character takes up one byte of video memory...

so you're saying the speed difference is because of scrolling text? If that's true, what about starting the emerge in a screen session and detach it while compilation, so there would be no visible scrolling and usage of video memory? You could always monitor the emerging process by checking the emerge.log.

At least on my old laptop I'm quite positive memory usage (only 256MB) is the main problem, and saving overhead for X and kde is the key for faster compilation times, besides using distcc.

But then again, can't hurt to test

[Corona688]

so you're saying the speed difference is because of scrolling text?

Bingo. I can't find it, but I think someone managed a speedup of around 5-10% with that xterm flag. Remember, while the xterm's printing, that's time by definition spent not compiling -- even if there's multiple jobs, they all have to wait for the output window to stop blocking. It's CC output -> pipe -> virtual TTY -> domain socket -> X11 -> video memory instead of CC output -> virtual TTY -> video memory. And there's a lot of printing going on.

And framebuffer consoles, well... They scroll so slow you can watch it.

If that's true, what about starting the emerge in a screen session and detach it while compilation, so there would be no visible scrolling and usage of video memory? You could always monitor the emerging process by checking the emerge.log.

I don't know much about screen, but that sounds sensible.

At least on my old laptop I'm quite positive memory usage (only 256MB) is the main problem, and saving overhead for X and kde is the key for faster compilation times, besides using distcc.

There's an easy way to test that -- run a compile in a physical console while X is running. Ctrl-alt-F1 brings you to a real text console(as do F2-F6, you get six seperate consoles), ctrl-alt-f7 brings you back to X.

[addeman]

Results with 'time emerge gaim'

TEST1: 6M 12.566S
TEST2: 4M 46.675S

That makes an emerge from the console in this test roughly 23% faster than in my normal operating mode.

Have you considered that after having done the first compile some results remain in RAM? Maybe a restart between the tests would give a more accurate result.

I also belive that the tests should be done in screen or similar if you want to test the overhead of running X and the various other services.

To test the overhead of a just konsole the test should be run in konsole vs. konsole + detached screen.

Just my thoughts.

Best regards
addeman

[Bornio]

i discovered the oppotise.
time car /usr/share/words on konsole @ full screen took about 3.8 seconds. in normal Console, it took about 17 seconds
more so, shrinking the size of Konsole to the smallest possible size resulted in times of 0.5 seconds
it seems like the speed in konsole (and hence xterm) is relevant to the size of the window needing to be rendered.

Also, i saw no speed ups/downs when changing fonts or encoding.