On 2009.04.11 11:06:17 -0700, Linus Torvalds wrote: > > > On Sat, 11 Apr 2009, Björn Steinbrink wrote: > > > > And for completeness, here are the results for linux-2.6.git > > > > | With my patch | With your patch on top > > -----|---------------|----------------------- > > VSZ | 460376 | 407900 > > RSS | 292996 | 239760 > > time | 0:14.28 | 0:14.66 > > Ok, it uses less memory, but more CPU time. That's reasonable - we "waste" > CPU time on doing the extra free's, and since the memory use isn't a huge > constraining factor and cache behavior is bad anyway, it's then actually > slightly slower. > > > And again, the new pack is slightly worse than the old one > > (window=250, --depth=250). > > Old: 240238406 > > New: 240280452 > > > > But again, it's negligible. > > Well, it's sad that it's consistently a bit worse, even if we're talking > just small small fractions of a percent (looks like 0.02% bigger ;). > > And I think I can see why. The new code actually does a _better_ job of > the resulting list being in "recency" order, whereas the old code used to > output the root trees all together. Now they're spread out according to > how soon they are reached. Hm, I don't think that was the case. When iterating over the commits, process_tree was called with commit->tree, and that added the root tree to the objects array as well as walking it to add all referenced objects. And yep, the 'old' "rev-list --all-objects" shows for example: ebace34d059216b3573cd67a83068d2eafe2f2e7 read-cache.c a869cb0789d8ad87f04d28dd9b703f3ff343a4a7 497a05b8fa8e9aa3a5db9b42e5c50392f352d2b4 cache.h 91b2628e3c18e7f75e477c24197d9ef2eca14125 read-cache.c 6862d1012681cd6812ab9bfe1a866446f92a7c91 read-tree.c a869cb0 being a root tree, inbetween two blobs. Björn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html