[interfacekit] Re: BString patch suggestion and some questions,too

On 2003-11-03 at 09:54:39 [+0100], you wrote:
> 
> > I'm not so sure, if that's a good idea. This will cause the 
> > implementation to
> > doubly touch the new space in the cases where _GrowBy() and _OpenAtBy() 
> > are
> > used, thus decreasing performance. In case of LockBuffer() it will even be
> > worse, if the allocated size is far greater than the actually used one.
> 
> I'm also against initializing the new space to '\0'. BString isn't exactly 
> fast in its allocations,
> so I don't think it's a good idea to slow it even more.
> One of the things I wanted to do is allocate memory in blocks (like 
> BMallocIO, BRegion, or any sane class which deals which allocations), 
> instead of every time the BString is
> truncated, or every time something is appended. Unfortunately, it isn't 
> possible without breaking binary compatibility.

Is that true? You can store more information a similar way as it is already 
done with the length -- in space allocated before the currently exposed data. 
Though, for the time being I would suggest to leave it as it is and rethink 
the implementation for R2.

> > BTW, it might be a good idea to not allocate memory, when _GrowBy() is 
> > asked
> > to create an empty string, but rather free the previously allocated memory
> > (if any) and set _privateData to NULL.
> 
> Yeah, that's one of the things I was unsure about.... adding an extra check 
> for (size == 0) was an idea, but then I discarded it, since I tought that 4 
> bytes "wasted" weren't a big deal...
> Moreover, I tought that freeing that memory was more heavy than keeping 
> those 4bytes around...

Whether you free() it or realloc() it shouldn't really matter, I suspect.

CU, Ingo

Other related posts: