Re: [PATCH 00/13] object store: alloc

2018-05-07 Thread Stefan Beller
Hi Junio, On Mon, May 7, 2018 at 7:05 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> This applies on top of sb/oid-object-info and is the logical continuum of >> the series that it builds on; this brings the object store into more of >> Gits code,

Re: [PATCH 00/13] object store: alloc

2018-05-07 Thread Junio C Hamano
Stefan Beller writes: > This applies on top of sb/oid-object-info and is the logical continuum of > the series that it builds on; this brings the object store into more of > Gits code, removing global state, such that reasoning about the state of > the in-memory

Re: [PATCH 00/13] object store: alloc

2018-05-03 Thread Stefan Beller
On Wed, May 2, 2018 at 11:22 AM, Duy Nguyen wrote: > I think the two have quite different characteristics. alloc.c code is > driven by overhead. struct blob is only 24 bytes each and about 1/3 > the repo is blobs, and each malloc has 16 bytes overhead or so if I > remember

RE: [PATCH 00/13] object store: alloc

2018-05-02 Thread Jameson Miller
> -Original Message- > From: Duy Nguyen <pclo...@gmail.com> > Sent: Wednesday, May 2, 2018 2:23 PM > To: Jameson Miller <jam...@microsoft.com> > Cc: Stefan Beller <sbel...@google.com>; Git Mailing List <git@vger.kernel.org> > Subject: Re: [PA

Re: [PATCH 00/13] object store: alloc

2018-05-02 Thread Duy Nguyen
Git Mailing List <git@vger.kernel.org>; Jameson Miller >> <jam...@microsoft.com> >> Subject: Re: [PATCH 00/13] object store: alloc >> >> On Tue, May 1, 2018 at 11:33 PM, Stefan Beller <sbel...@google.com> wrote: >> > I also debated if it is worth conver

RE: [PATCH 00/13] object store: alloc

2018-05-02 Thread Jameson Miller
> -Original Message- > From: Duy Nguyen <pclo...@gmail.com> > Sent: Wednesday, May 2, 2018 1:02 PM > To: Stefan Beller <sbel...@google.com> > Cc: Git Mailing List <git@vger.kernel.org>; Jameson Miller > <jam...@microsoft.com> > Subject: Re:

Re: [PATCH 00/13] object store: alloc

2018-05-02 Thread Duy Nguyen
On Tue, May 1, 2018 at 11:33 PM, Stefan Beller wrote: > I also debated if it is worth converting alloc.c via this patch series > or if it might make more sense to use the new mem-pool by Jameson[1]. > > I vaguely wonder about the performance impact, as the object allocation >

[PATCH 00/13] object store: alloc

2018-05-01 Thread Stefan Beller
This applies on top of sb/oid-object-info and is the logical continuum of the series that it builds on; this brings the object store into more of Gits code, removing global state, such that reasoning about the state of the in-memory representation of the repository is easier. My original plan was