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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
