[Top][All Lists]
[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
- [Duplicity-talk] dbus patch, Michael Terry, 2008/11/02
- [Duplicity-talk] Re: dbus patch, Michael Terry, 2008/11/02
- Re: [Duplicity-talk] Re: dbus patch, Dan Muresan, 2008/11/02
- Re: [Duplicity-talk] Re: dbus patch, Michael Terry, 2008/11/02
- Re: [Duplicity-talk] Re: dbus patch, Dan Muresan, 2008/11/02
- Re: [Duplicity-talk] Re: dbus patch,
Michael Terry <=
- Re: [Duplicity-talk] Re: dbus patch, Dan Muresan, 2008/11/04
- Re: [Duplicity-talk] Re: dbus patch, Michael Terry, 2008/11/04
- Re: [Duplicity-talk] Re: dbus patch, Dan Muresan, 2008/11/04
- Re: [Duplicity-talk] Re: dbus patch, Edgar Soldin, 2008/11/04
- [Duplicity-talk] asynchronous-uploads, Richard Scott, 2008/11/04
- Re: [Duplicity-talk] asynchronous-uploads, Peter Schuller, 2008/11/07
- Re: [Duplicity-talk] Re: dbus patch, Michael Terry, 2008/11/05
- Re: [Duplicity-talk] Re: dbus patch, Dan Muresan, 2008/11/06
- Re: [Duplicity-talk] Re: dbus patch, Michael Terry, 2008/11/06
- Re: [Duplicity-talk] Re: dbus patch, Dan Muresan, 2008/11/06