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 -- 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