From: Eric Mahurin <eric.mahurin@...>
Date: 2008-02-11T08:49:42+09:00
Subject: Re: very bad character performance on ruby1.9

------=_Part_34848_31629565.1202687389558
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Feb 10, 2008 4:06 PM, Matthias W=E4chter <matthias@waechter.wiz.at> wrot=
e:

> 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 t=
o
> 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.

------=_Part_34848_31629565.1202687389558
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Feb 10, 2008 4:06 PM, Matthias W=E4chter &lt;<a href=3D"mailto:matthias@=
waechter.wiz.at">matthias@waechter.wiz.at</a>&gt; wrote:<br><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"border-left: 1px sol=
id rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Eric,<br><br>Eric Mahurin schrieb:<br><div class=3D"Ih2E3d">&gt; I&#39;d li=
ke to propose that at least ASCII characters in ruby 1.9 be made into<br>&g=
t; immediates:<br>&gt;<br>&gt; * at a minimum, characters should be read-on=
ly/frozen. &nbsp;Allowing them to be<br>
&gt; mutable will inhibit many future optimizations.<br>&gt; * give (small)=
 characters a separate class with string-like (read-only)<br>&gt; functiona=
lity.<br>&gt; * possibly add a base class that String and this new characte=
r class would<br>
&gt; be a descendent of.<br>&gt; * eventually make this small (i.e. ASCII o=
r even unicode) character class<br>&gt; have immediate objects<br><br></div=
>I would not limit it to ASCII characters but would directly go for<br>
Unicode. As the Unicode universe requires at most 21 bits for addressing<br=
>any code point, we could easily make a separate class and immediate<br>4-b=
it lead specifier for it, f.e. 0xE, like 0xC is for object pointers,<br>
to fit any 32 bit integer.<br><br>Has there been work or discussions on thi=
s topic before?<br><font color=3D"#888888"><br>- Matthias</font></blockquot=
e><div><br>I agree, making all (unicode) characters immediate would be idea=
l.&nbsp; I wasn&#39;t sure whether there was enough space in the object han=
dle to encode it.<br>
<br>Another option that would achieve similar performance (but have higher =
memory overhead) would be to have singleton character objects ready to be r=
eferenced at anytime.&nbsp; When a character is to be returned, it would lo=
okup the character object in some table (array or hash).&nbsp; This way ?a,=
 &quot;abc&quot;[0], and StringIO.new(&quot;abc&quot;).getc would all refer=
 to the same character object (with a String-like API).&nbsp; Querying char=
acters wouldn&#39;t create any new objects.<br>
<br>Still, the first thing that needs to be done before thinking about any =
of these optimizations is to make character object immutable/read-only/froz=
en?<br><br>What would be the reason to allow character objects to be mutabl=
e in ruby 1.9?&nbsp; They aren&#39;t in 1.8.6 because they are Fixnum&#39;s=
.&nbsp; Allowing them to be mutable just prevents future optimizations.<br>
<br></div></div>

------=_Part_34848_31629565.1202687389558--