Messages in this thread | | | Date | Wed, 24 Oct 2007 10:20:36 -0500 | From | Matt Mackall <> | Subject | Re: [PATCH 1/4] stringbuf: A string buffer implementation |
| |
On Tue, Oct 23, 2007 at 07:49:20PM -0600, Matthew Wilcox wrote: > On Tue, Oct 23, 2007 at 05:11:16PM -0500, Matt Mackall wrote: > > You might want to consider growing the buffer by no less than a small > > constant factor like 1.3x. This will keep things that do short concats > > in a loop from degrading to O(n^2) performance due to realloc and > > memcpy. > > I looked at slab and slub, and would grow the buffer by no less than > 1.5x each time, thanks to the buckets. I'd initially implemented 2x, > but switched to allocating size+1 and calling ksize() as being a more > efficient implementation.
Fair enough.
> I presume slob is different? Actually, slob doesn't seem to > provide krealloc, so I think stringbuf won't work on slob. Will you > have time to fix this?
http://lxr.linux.no/source/mm/slob.c#L207
Yep, slob is different, it has no kmalloc buckets.
> > Should probably just bite the bullet and pass a flag. > > Hrm. > > extern void sb_printf(struct stringbuf *sb, gfp_t gfp, const char *fmt, ...) > __attribute__((format(printf, 3, 4))); > > ? Any objections?
Fine by me.
> > > +#define INITIAL_SIZE 32 > > > > Too small. That will guarantee that most users end up doing a realloc. > > Can we have 128 instead? > > I don't care. Sure!
Most of these objects will have very short lifetimes, so there's very little downside.
-- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |