RE: inlining and string concatenation

["Boehm, Hans" <hans_boehm at hp dot com>]

Has anyone thought about using a rope-like data structure (cf.
http://reality.sgi.com/boehm/ropeimpl.html, or the cord implementation in
the garbage collector distribution
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/cordh.txt) for
Strings?  It seems to be possible.  If StringBuffers are represented as
something like the "extensible cords" in the collector distribution, i.e. as
a cord plus a buffer of additional characters, then some of the typical
operations should get a bit cheaper, since every character is copied exactly
once.  (Insert is probably more expensive for short strings, and cheaper for
long ones.  Reverse is bound to be more expensive.)

Hans 

-----Original Message-----
From: Bryce McKinlay [mailto:bryce@albatross.co.nz]
Sent: Monday, May 01, 2000 3:59 PM
To: Tom Tromey
Cc: Java Discuss List
Subject: Re: inlining and string concatenation


Tom Tromey wrote:

> It seems to me that we could allocate the String[] (or the C++
> equivalent, really -- we don't need the object header) on the stack.
> Since string concatenation behavior is largely known at compile time,
> we can just have "tmp[slot] = <whatever>.toString()" directly
> generated by the compiler.

Yes. I just wanted to point out that even my naive implementation did a
lot better than the existing one, so this is a big performance hotspot.

regards

  [ bryce ]