Re: [PATCH 0/2] strbuf: improve API

2016-06-24 Thread Jeff King
On Thu, Jun 02, 2016 at 01:11:56PM +0200, Michael Haggerty wrote: > On 06/01/2016 11:07 PM, Jeff King wrote: > > On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote: > > > >> I have no idea if those ideas would work. But I wouldn't want to start > >> looking into either of them without

Re: [PATCH 0/2] strbuf: improve API

2016-06-02 Thread William Duclot
On Thu, Jun 02, 2016 at 02:58:22PM +0200, Matthieu Moy wrote: > Michael Haggerty writes: > >> 1. The amount of added code complexity is small and quite >>encapsulated. > > Actually, STRBUF_OWNS_MEMORY can even be seen as a simplification if > done properly: we already

Re: [PATCH 0/2] strbuf: improve API

2016-06-02 Thread Matthieu Moy
Michael Haggerty writes: > 1. The amount of added code complexity is small and quite >encapsulated. Actually, STRBUF_OWNS_MEMORY can even be seen as a simplification if done properly: we already have the case where the strbuf does not own the memory with

Re: [PATCH 0/2] strbuf: improve API

2016-06-02 Thread Michael Haggerty
On 06/01/2016 11:07 PM, Jeff King wrote: > On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote: > >> I have no idea if those ideas would work. But I wouldn't want to start >> looking into either of them without some idea of how much time we're >> actually spending on strbuf mallocs (or how

Re: [PATCH 0/2] strbuf: improve API

2016-06-01 Thread Jeff King
On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote: > I have no idea if those ideas would work. But I wouldn't want to start > looking into either of them without some idea of how much time we're > actually spending on strbuf mallocs (or how much time we would spend if > strbufs were used

Re: [PATCH 0/2] strbuf: improve API

2016-06-01 Thread David Turner
On Wed, 2016-06-01 at 16:09 -0400, Jeff King wrote: > On Wed, Jun 01, 2016 at 03:50:29PM -0400, David Turner wrote: > > > On Wed, 2016-06-01 at 03:42 -0400, Jeff King wrote: > > > 2. Do caching tricks for strbufs used in tight loops. For > > > example, > > > have strbuf_release() throw its

Re: [PATCH 0/2] strbuf: improve API

2016-06-01 Thread Jeff King
On Wed, Jun 01, 2016 at 03:50:29PM -0400, David Turner wrote: > On Wed, 2016-06-01 at 03:42 -0400, Jeff King wrote: > > 2. Do caching tricks for strbufs used in tight loops. For example, > > have strbuf_release() throw its buffer into a last-used cache, > > and > > let the next

Re: [PATCH 0/2] strbuf: improve API

2016-06-01 Thread David Turner
On Wed, 2016-06-01 at 03:42 -0400, Jeff King wrote: > 2. Do caching tricks for strbufs used in tight loops. For example, > have strbuf_release() throw its buffer into a last-used cache, > and > let the next strbuf_grow() use that cache entry. This cuts > malloc() > out of the

Re: [PATCH 0/2] strbuf: improve API

2016-06-01 Thread Jeff King
On Mon, May 30, 2016 at 01:32:08PM +0200, Remi Galan Alfonso wrote: > William Duclot writes: > > This patch series implements an improvment of the strbuf API, allowing > > strbuf to use preallocated memory. This makes strbuf fit to be used > > in

Re: [PATCH 0/2] strbuf: improve API

2016-05-30 Thread Remi Galan Alfonso
William Duclot writes: > This patch series implements an improvment of the strbuf API, allowing > strbuf to use preallocated memory. This makes strbuf fit to be used > in performance-critical operations. > > The first patch is simply a preparatory work,

[PATCH 0/2] strbuf: improve API

2016-05-30 Thread William Duclot
This patch series implements an improvment of the strbuf API, allowing strbuf to use preallocated memory. This makes strbuf fit to be used in performance-critical operations. The first patch is simply a preparatory work, adding tests for existing strbuf implementation. Most of the work is made in