Re: very bad character performance on ruby1.9

On Feb 10, 2008 4:06 PM, Matthias W臘hter <[e-mail]> wrote:

> Eric,
>
> Eric Mahurin schrieb:
> > I'd like to propose that at least ASCII characters in ruby 1.9 be made
> into
> > immediates:
> >
> > * at a minimum, characters should be read-only/frozen.  Allowing them to
> be
> > mutable will inhibit many future optimizations.
> > * give (small) characters a separate class with string-like (read-only)
> > functionality.
> > * possibly add a base class that String and this new character class
> would
> > be a descendent of.
> > * eventually make this small (i.e. ASCII or even unicode) character
> class
> > have immediate objects
>
> I would not limit it to ASCII characters but would directly go for
> Unicode. As the Unicode universe requires at most 21 bits for addressing
> any code point, we could easily make a separate class and immediate
> 4-bit lead specifier for it, f.e. 0xE, like 0xC is for object pointers,
> to fit any 32 bit integer.
>
> Has there been work or discussions on this topic before?
>
> - Matthias


I agree, making all (unicode) characters immediate would be ideal.  I wasn't
sure whether there was enough space in the object handle to encode it.

Another option that would achieve similar performance (but have higher
memory overhead) would be to have singleton character objects ready to be
referenced at anytime.  When a character is to be returned, it would lookup
the character object in some table (array or hash).  This way ?a, "abc"[0],
and StringIO.new("abc").getc would all refer to the same character object
(with a String-like API).  Querying characters wouldn't create any new
objects.

Still, the first thing that needs to be done before thinking about any of
these optimizations is to make character object immutable/read-only/frozen?

What would be the reason to allow character objects to be mutable in ruby
1.9?  They aren't in 1.8.6 because they are Fixnum's.  Allowing them to be
mutable just prevents future optimizations.