GNU bug report logs - #6524
du now uses less than half as much memory, sometimes

Previous Next

Full log

Message #59 received at 6524 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 6524 <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#6524: du now uses less than half as much memory, sometimes
Date: Sun, 04 Jul 2010 16:14:51 +0200

Jim Meyering wrote:
> Jim Meyering wrote:
>> This is just a preliminary heads-up.  At least one detail must be
>> addressed before I push: I haven't written justification for the
>> change to hash.c (I confess that I don't remember -- parts of this
>> change date back to Dec 2008 ;-)
>
> I've pushed the four change-sets I wrote.
> Here's Paul's improvement, including the touch-up changes I mentioned.
>
> Paul, one question I have is whether to include an initial_inode_set_size
> parameter in your di_set_alloc function.  That would make it more
> efficient in the event that an application happens to know in advance the
> number of inodes it will process (say if it's processing a single device
> and all of its inodes).  However, there's no rush to address that --
> you're welcome to push this as-is.
>
> Subject: [PATCH] du: improve device-inode tracking code
>
> The preceding implementation would not save space when most inode
> numbers have one of the top few bits set.  Remove that limitation
> by using a separate inode-managing set for each distinct device.

BTW, if someone can test this patch on a 32-bit system
on a tree with lots of hard-linked files that have inode numbers
of 2^32 or larger, it would be instructive to see how it compares
to the version of du before any of these changes.  I think it will
still save memory, but how does performance change in that case?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.