From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: drepper@cygnus.com Cc: egcs@cygnus.com Subject: Re: New STL implementation from SGI Date: Thu, 09 Jul 1998 17:02:00 -0000 Message-id: <199807100002.RAA10346@atrus.synopsys.com> References: X-SW-Source: 1998-07/msg00359.html I wrote: > > The real issue (whenever we decide to pick up the new STL) is the string > > class: do we use the SGI one, the existing one, or the one Ulrich Drepper > > is working on? Ulrich replies: > Actually Nathan is doing the work. Anyhow, we will not completely > abandom the version we have in the moment since on some platforms > space consumption is more important than speed and here the current > implementation we have is superior. Yes, the SGI implementation is basically a slightly different vector that is always null-terminated, meaning that there is no reference counting and string copy is a deep copy operation, but conversion to/from const char* is cheaper. I would prefer something that works more like what we have (reference counting). However, I am discouraged by the fact that we still don't have anything available for testing. I'd like to encourage the developers (e.g. you and Nathan) to make available even partially working code so that others can assist with testing, suggestions for improvement, etc. > To decide which version we use somebody will have to make measurements > with a thread-safe version of either implementation. My guess is that > the SGI version is faster since we don't have to care for locking. Actually I suspect that the SGI version will be slower as well as require more memory in some applications: if copying strings from place to place is common, but concatenation is less common, a deep copy may cost more than a reference count adjustment. But other operations are faster (e.g. get the string length without any indirection, c_str() is free etc). Because of the different implementation tradeoffs, just tell me which implementation you want to win and I will write you an appropriate benchmark. :-)