On Fri, Mar 01, 2019 at 07:22:47PM +0100, Alban Gruin wrote: > Le 01/03/2019 à 19:05, Eric Sunshine a écrit : > > On Fri, Mar 1, 2019 at 12:50 PM Alban Gruin <alban.gruin@xxxxxxxxx> wrote: > > -%<- > > Minor: It would probably be more efficient to check if the count is 0 > > first, and only search the list if not. > > > > By the way, how big is 'commits' likely to get? Will the linear scan > > done by commit_list_contains() become an issue? Should it be using a > > hash table instead? > > > > It depends on the amount of commits mentionned in stdin that are > reachable from the ref in name_ref(). If there is a lot of commit in > the input, it may effectively become a problem. Yeah, I think this is quadratic in the worst case. > I thought of adding a field to the rev_name structure for this purpose. > I think commit slabs are hash maps under the hood? They're not hash maps, but they're still O(1). Each commit struct is allocated a unique integer id, and the slab just keeps a dynamic array of one entry per commit. So they're actually faster than a hashmap (it's a pure index, no oideq() required). The downside is that they can use more memory than a hashmap if they're sparsely populated. However in your case, I think you'd load a couple of "struct commit" objects at the start, mark them as "1" in the slab, and then never mark any more as you traverse. So you'd only allocate entries for those tightly-packed initial ones. It seems like an ideal case for using a slab. -Peff
