Speed meets -v

…or: Why I will not copy files using a GUI

This document was inspired by a thread on a mailing-list I have subscribed. The thread was about the speed of different file-systems (ext2, ext3, reiser, xft, …) One of the folks timed the speed using the KDE-Drag’n’Drop function.

So I took the time to time different methods of copying files. I also tried different ‘locations’ like a regular TTY or an xterm at different window-sizes.

I did not take different file-systems into account, since I do not think that speed is an important issue when choosing the FS. If I want a logging-FS for security reasons, I don’t care for the speed-penalty I get for writing that log.

The box and its contents

I used an old P3-600 for this test. Debian Woody is installed pretty much out-of-the-box. That means that there were not much optimizations like DMA for the disks or the like.

For the tests, I copied the contents of /dev/hda1 (my root-partition) to /dev/hdb1 I used the ‘time’-command for timing. Read its manual-page for details

Here are some numbers for those interested

woody:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             3.9G  1.1G  2.6G  29% /
/dev/hdb1              19G  1.1G   16G   7% /mnt/hdb1
woody:~# uname -a
Linux woody 2.2.20-idepci #1 Sat Apr 20 12:45:19 EST 2002 i686 unknown
woody:~# find / | wc -l ; # Number of files
 144281

Ready, set, go!

Command	Environment	real	user	sys
cp -ax / /mnt/hdb1/	tty, 80x30 (should not matter)	15m21.664s	0m15.380s	5m6.830s
cp -axv / /mnt/hdb1/	tty, 80x30	22m8.563s	0m18.730s	4m3.590s
	xterm, 142x53	18m32.750s	0m30.840s	5m2.450s
	xterm, 80x30	17m27.710s	0m30.790s	5m5.190s
Drag'n'Drop	KDE	23m28s (Hand-timed, +- 5 seconds)	not available
rm -rf /dev/hdb2/*	tty, 80x30 (should not matter)	2m11.933s	0m0.400s	0m3.210s
rm -rfv /dev/hdb2/*	tty, 80x30	3m55.950s	0m3.420s	0m4.850s
	xterm, 142x53	2m20.204s	0m3.040s	0m4.720s
	xterm, 80x30	2m20.208s	0m3.220s	0m4.940s
Drag'n'Drop	gmc (konqueror did play tricks on me :-)	3m40s (Hand-timed, +- 5 seconds)

And what does this tell us?

File operations on commandline without the -v swich are fastest (by far!)
When being verbose, an xterm can be faster that a TTY (I did not expect that. Probably depends on your graphic-adaptor)
GUI is slowest. Not only by time.

But why is GUI so bad?

It took me several attempts to hand-time the Drag’n’Drop.

The system crashed when accessing /dev/mem (This was never a problem on the commandline!)
When I came back from my coffee, I noticed that a dialogbox was waiting for my answer. This box appeared quite a while after starting the operation.
When I came back from my second coffee, I had missed the end of operation. While this is not really important in real life, it shows how inaccurate the ‘remaining-time’ display is.

So judge yourself...

I am not against GUIs. But if you need to copy a lot of files, take the keyboard. I usually try out the command with -v and when I see it works like I want it to, I hit <ctrl>+C and restart without -v. That way I can also spot error-messages, which is hard or impossible with verbose on.

Copyright (c) by the authors.
Prior to editing, authors agreed to license their contributions by the terms of the GPL.
See our licensing page for details.

Linux® is a registered trademark of Linus Torvalds.

LinuxBasics.org

The community that helps people to run Linux