Re: food for thought re: string representations ["Boehm, Hans" <address@hidden>] RE: Re: [gclist] ref-counting performance cost

[Dirk Herrmann]

On Fri, 13 Oct 2000, Michael Livshin wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > Thus, if guile would be changed to use a copy-on-write string
> > implementation, every use of SCM_STRING_CHARS would have to be
> > revisited with respect to thread safety, making sure that the
> > corresponding pointer remains valid throughout its use.
> 
> which kinda begs the question what exactly is won by using
> copy-on-write...
> 
> the more I think about it, the more I convince myself that the SGI STL
> implementors did the right thing by providing _two_ string
> implementations, where one (basic_string) is simple and OK for short
> strings, and the other (rope) is better for large strings when the
> cost of copying becomes large and the cost of added synchronization
> becomes acceptable by comparison.  perhaps we could do the same, with
> the representation chosen authomatically by Guile when a string is
> created.

That solution would still invalidate uses to SCM_STRING_CHARS, since in
all situations where you now expect a string, you then would have to
distinguish between two different string types.

But I agree with you that it is questionable whether a copy-on-write
string implementation is really a good idea.  It is possible, but requires
a lot more thought on the C level to get things right in the context of
threading.

I have prepared a new version of the newstrings as a sample implementation
of memory-regions and copy-on-write strings, incorporating the suggestions
from Keisuke.  Thread support is given in form of comments, stating where
I believe that mutex locking and unlocking would have to be performed.  If
you look at the /* Lock string */ and /* Unlock string */ comments, for
example in the implementation of newstrings.c:newstring_print or
newstrings.c:scm_newstring_set_x it appears how complicated things can
be :-()

If you would like to get an impression of the performance without
threading, you can try the added benchmark suite.  Without threading
things look quite OK.  How much performance influence threading will have
will depend on the mutex locking/unlocking performance.

Best regards
Dirk

newstrings.tgz
Description: GNU Unix tar archive