Re: [PATCH] alloc.c: replace alloc by mempool

2018-05-07 Thread Junio C Hamano
Stefan Beller writes: > The replacement with mem-pool might be easier than making sure > that alloc.c has no globals and handles allocations per repository > correctly. It would make the sb/object-store-alloc series shorter than > it currently is, and maybe easier to review the code. > > However

Re: [PATCH] alloc.c: replace alloc by mempool

2018-05-07 Thread Stefan Beller
On Mon, May 7, 2018 at 5:37 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >>> So I think we could just replace it for now and optimize again later, if it >>> turns out to be a problem. I think the easiest optimisation is to increase >>> the allocation size of having a lot more objects per mp_b

Re: [PATCH] alloc.c: replace alloc by mempool

2018-05-07 Thread Junio C Hamano
Duy Nguyen writes: >> So I think we could just replace it for now and optimize again later, if it >> turns out to be a problem. I think the easiest optimisation is to increase >> the allocation size of having a lot more objects per mp_block. > > Yeah. I also tested this from a different angle: me

Re: [PATCH] alloc.c: replace alloc by mempool

2018-05-04 Thread Duy Nguyen
On Fri, May 4, 2018 at 12:18 AM, Stefan Beller wrote: > I just measured on git.git and linux.git (both of which are not *huge* by > any standard, but should give a good indication. linux has 6M objects, > and when allocating 1024 at a time, we run into the new block allocation > ~6000 times). > >

[PATCH] alloc.c: replace alloc by mempool

2018-05-03 Thread Stefan Beller
Signed-off-by: Stefan Beller --- >> The reason for my doubt is the potential quadratic behavior for new >> allocations, >> in mem_pool_alloc() we walk all mp_blocks to see if we can fit the requested >> allocation in one of the later blocks. >> So if we call mem_pool_alloc a million times, we ge