duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Re: dbus patch


From: Michael Terry
Subject: Re: [Duplicity-talk] Re: dbus patch
Date: Tue, 4 Nov 2008 13:15:17 -0500

On Sun, Nov 2, 2008 at 4:29 PM, Dan Muresan <address@hidden> wrote:
> OK, I suppose I wasn't very clear; my concern was the number of
> dependencies / ease of installation -- not performance.

That makes more sense.  I don't know why I assumed performance.

A quick reminder to followers of the conversation -- we're talking
about a possible future change of integrating the glib main loop into
duplicity as a non-optional dependency and the resource drain that
would incur.

So, since I didn't actually have any information about RAM/disk usage
of glib, I tried to get some.  This is all on my Ubuntu Intrepid
laptop.

On-disk space:
  python-gobject: 1088
  libglib2.0-0: 1768

So the addition of glib is ~3M disk.  That's not bad, all told.  And
most people already have the packages.

So what about RAM?  I got the following stats by forcing a sleep right
after initialization (before even command line parsing) and checking
top.

No dbus (baseline):
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  8249 mike      20   0  9064 6280 2500 S    0  0.2   0:00.10 duplicity-bin

With just gobject:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  14357 mike      20   0 11048 7364 3036 S    0  0.2   0:00.18 duplicity-bin

  Increase in VIRT from baseline: 1984
  Increase in RES from baseline:  1084
  Increase in SHR from baseline:   536

With gobject + dbus:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  8295 mike      20   0 12336 8456 3476 S    0  0.2   0:00.16 duplicity-bin

  Increase in VIRT from baseline: 3272
  Increase in RES from baseline:  2176
  Increase in SHR from baseline:   976


So the case under discussion (adding just gobject) raised VIRT by 2M,
RES by 1M and SHR by 0.5M.  I never seem to get this right, but I
believe the relevant number there is RES?  The space that duplicity is
actually consuming in real memory.

>From my perspective (targetting desktop users), 1M isn't bad, but Dan,
you're coming at this from a tiny server perspective.  Would 1M break
the duplicity bank?


Also, Ken as maintainer, I'd like some feedback on the whole strategic
vision of dbus, glib integration, and/or my patch.

(Ken, you mentioned a move to sourceforge?  Should we not start
claiming the dbus name 'org.nongnu.duplicity' then?  :)  I'd also give
a shoutout to launchpad if you're shopping around for project hosts --
I was never very thrilled with SF.)

-mt




reply via email to

[Prev in Thread] Current Thread [Next in Thread]