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. The object sorting code _should_ sort them by type, name and size (and thus the pack generation should generate the same deltas), but the name hashing is probably weak enough that it doesn't always do a perfect job, and then we likely get a slightly worse pack. But it would be good to really understand that part. It's a _small_ downside, but it's a downside. But it's interesting to note how the bigger gentoo case actually improved in performance, probably because by then the denser memory use actually meant that we had noticeably better cache and TLB behavior. So the patch helps the bad case, at least. Linus -- 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