On Tue, Aug 28, 2007 at 10:15:01AM +0100, Johannes Schindelin wrote:
Yes, I considered making it dynamic, which would probably end up saving
quite a bit of memory (since most commits use many fewer than 32) I
think 32 is a reasonable limit in general, since at some point, do you
really want to see that many merge traversals in the resulting name?
Let's say we allocate dynamically. The average per-commit number of
stored merge traversals for linux-2.6 is 1.79. Each traversal is 5 bytes
(though I think we could easily drop it to 3 or 4 -- do we expect
generation counters larger 1.7 million?), for an average of 10 bytes
stored per commit.
Now compare that to the fact that we no longer need to strdup the
tip_name. "tags/v2.6.22-rc1~1686^2~1" is _25_ bytes. So it's a net win
(though not with a static array, obviously).
I am all for making a trade-off if there is a reason. But if memory
usage is your only concern, I think we can have our cake and eat it too.
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html