On Mon, Sep 10, 2007 at 10:35:03AM +0000, Pierre Habouzit wrote: > This new proposal has this changed since last proposal: > > * the strbuf patch also changed strbuf_init and strbuf_read to take an > extra size hint. If it's 0 it works like before. If non-zero, it's > the size the buffer will have at start for strbuf_init, or the first > "grow" asked for strbuf_read (so that if you made a "stat" on your > file, you can realloc once only now, or if you know that you will > read small datas, you will avoid the default 8k memory buffer). Oh I wanted to say, in many places we do a strbuf_init(..., 0). Like for the buffer used to store pretty-printed commits. We may want to do some preemptive allocations, because it makes the "interpolate" calls be called twice, so I'm pretty sure some review of people with more knowledge than me of the overall git internals to tweak those initial sizes may see some marginal improvements happen. Such places are easy to find: grep -r "strbuf_init([^,]*, 0)" will do. As a side note, I think I'm quite done with strbufs in git. There is till one place: builtin-apply.c uses its own buffer API, but sometimes in a quite twisted way that does not works nicely with strbufs as is, though I don't like to see many buffers implementations. I may be going to try to get rid of buffer_desc's at some point, but the patch is non trivial hence I left it alone. That done, I'm still keen on continuing some code janitor work in git, so if people have any clues of kind of codes that are duplicated, or that would benefit from a refactor, please point me to it, I'd gladly improve things that way. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpHlcrNKoow3.pgp
Description: PGP signature
