On 07/04/10 07:14, Jim Meyering wrote: > 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?
I looked into this and found a performance hit due to the 64-bit % in the code I proposed. I hadn't thought the % would be a CPU bottleneck! Anyway, I fixed this by XORing the two halves of the 64-bit dividend before doing a 32-bit %, and this caused the resulting code to run about as fast as coreutils 8.5 (any difference was below the resolution of the time stamp on my "du cu*" benchmark; I artificially modified my benchmark by adding 2**32 to all the inode numbers). I'll submit an updated patch shortly.
