Re: [PATCH v2] use a hashmap to make remotes faster

2014-09-05 Thread Stefan Beller
On 29.07.2014 16:43, Patrick Reynolds wrote: Remotes are stored as an array, so looking one up or adding one without duplication is an O(n) operation. Reading an entire config file full of remotes is O(n^2) in the number of remotes. For a repository with tens of thousands of remotes, the

Re: [PATCH v2] use a hashmap to make remotes faster

2014-09-05 Thread Jeff King
On Fri, Sep 05, 2014 at 11:55:06AM +0200, Stefan Beller wrote: struct remote { + struct hashmap_entry ent; /* must be first */ + I stumbled about this comment /* must be first */ when reading the changelog. Why does it need to be first? Is it a common reason I'm just not aware

Re: [PATCH v2] use a hashmap to make remotes faster

2014-07-30 Thread Junio C Hamano
Please don't do this: Content-Type: multipart/related; boundary=MIME delimiter for sendEmail-128858.688128279 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH v2] use a hashmap to make remotes faster

2014-07-29 Thread Patrick Reynolds
Remotes are stored as an array, so looking one up or adding one without duplication is an O(n) operation. Reading an entire config file full of remotes is O(n^2) in the number of remotes. For a repository with tens of thousands of remotes, the running time can hit multiple minutes. Hash tables

Re: [PATCH v2] use a hashmap to make remotes faster

2014-07-29 Thread Jeff King
On Tue, Jul 29, 2014 at 02:43:39PM +, Patrick Reynolds wrote: Remotes are stored as an array, so looking one up or adding one without duplication is an O(n) operation. Reading an entire config file full of remotes is O(n^2) in the number of remotes. For a repository with tens of