On Mon, Oct 18, 2010 at 4:41 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 18.10.2010, at 13:49, Colin Putney wrote:
>
> > On Mon, Oct 18, 2010 at 1:38 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> >> I think immediate characters are much more generally useful, especially
> >> considering unicode.  The current implementation of only codes 0 to 255
> >> being == is error-prone.
> >
> > I enthusiastically agree. I think string handling in Squeak is pretty
> > weak, and having efficient Characters would provide a solid basis for
> > improving it.
>
> Disagree.
>
> You don't want to be manipulating single characters if speed matters. Much
> better to add primitive support to speed up WideStrings.
>

But there are many places in the system that deal with characters.  They are
an extremely common datatype in the compiler, in the UI.

Also, adding more immediate objects will slow down the system as a whole. I
> remember changing the tag bit check in the early days of Squeak did have a
> performance impact. Whether new immediates would result in a net speed win
> remains to be seen.
>

It won't slow the system down, and I speak form VW experience where we had
either immediate characters and integers (32-bit) or immediate characters
integers and floats (64-bits).  You're basically talking about the cost of
masking by 1 or masking by 3 (or 7 in 64-bits) and on last century's
machines that could make a difference.  But on contemporary hardware it
makes no difference; only memory access makes a difference and adding
immediate characters can only reduce memory access.  Therefore it will
likely speed-up the system, but will certainly not slow it down.


> - Bert -
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101018/ef5012b1/attachment.htm