Re: [PATCH 5/7] revert: free revs->cmdline.rev

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 22, 2012, 20:40 UTC
Message-ID: <20120522204014.GA19789@burratino>
In-Reply-To: <20120522.220142.31626389365969573.chriscool@tuxfamily.org>

Christian Couder wrote:

> About the constantly growing hash table, perhaps it should be taken
> care of in a try_to_free_routine() used by xmalloc and other such
> functions. And no I don't know much about libgit2.

Hm. At first glance that sounds interesting (some kind of mark-and-sweep garbage collection, so at least allocation would never _fail_ due to too large a multipick). At second glance it is less exciting, since the logic would only kick in when malloc() fails, and if I have a lot of swap then my system will have slowed to a crawl long before then.

Here are a couple of alternative ideas, with no code to back them up.

A. Save a copy of obj_hash after revision traversal and before cherry-picking anything, and reset the table to that state after every (let's say) 5 commits cherry-picked. Or perhaps empty the table completely after every 5 commits or so cherry-picked.

B. Re-exec git using "git sequence --continue" so everything gets allocated anew after every 5 commits or so.

That second idea sounds pretty ugly, but it would probably be effective. On Windows it's fork(), not execve(), that is expensive, right? :)

Just musing, Jonathan