0.7.6 slower than 0.6.1

Ben Escoto bescoto@stanford.edu
Sat, 15 Jun 2002 18:54:19 -0700

Content-Type: text/plain; charset=us-ascii

>>>>> "KS" == Kevin Spicer <Spicer>
>>>>> wrote the following on Sun, 16 Jun 2002 00:56:23 +0100

  KS>   Interesting you mention the atime stuff (it is 7 that adds
  KS> this option BTW), I noticed that 0.7.6 doesn't seem to change
  KS> the atime

I think the way it should work is if a file just has a different
atime, it is not considered to have changed and won't be updated.  If
it is marked as changed, then its atime will be updated along with the
other stuff.

  KS> I'm not that convinced that its all filesystem related though,
  KS> I've just had a quick glance at top (rdiff-backup is running at
  KS> present) the 'top' process is python (around 80% CPU) cpu states
  KS> are about 80% user and 5-10% iowait.

Yes, rdiff-backup eats a lot of CPU.  There are undoubtedly
inefficiencies along the lines Dean mentioned, but for most systems
CPU (or possibly bandwidth) will be the limiting factor.

    Code that would be relatively innocuous in C can take up a lot of
time in Python.  See


for a good language speed comparision, with an overview at


The scripting lanuages are generally about 20x or less slower than C,
when the builtin scripting functions (like Python's fileIO, splitting
strings, etc.) can do a moderate share of the work.  When they can't
the ratio drops to 200:1 (see the tests "Method Calls" and "Nested

    Anyway, 0.9.x will be distributed as a bunch of .py[c] files
instead of one big script (I am working on exploding it now), and
should be a lot faster, especially after I rewrite some important
parts in C.

Ben Escoto

Content-Type: application/pgp-signature

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001