Ah, no, I was thinking that String>>at: and asciiValue would be accelerated

            char := sourceString at: lastIndex.
            ascii := char asciiValue + 1.


2013/10/23 Eliot Miranda <eliot.miranda at gmail.com>

> Hi Nicolas,
>
>
> On Tue, Oct 22, 2013 at 12:58 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>> Well, it's probable that all these indirections were too much, but
>> restoring the primitive makes a difference with this mini-benchmark under
>> interpreter VM:
>>
>> | text |
>> text := Compiler evaluate: (FileStream fileNamed: 'text.st')
>> contentsOfEntireFile.
>> MessageTally spyOn: [[100 timesRepeat: [(NewParagraph new)
>>         compose: text
>>         style: TextStyle default copy
>>         from: 1
>>         in: ( 0 at 0 corner: 569 at 9999999)]] timeToRun ].
>>
>> with text extracted from "Working With Squeak" workspace, goes from 713ms
>> down to 261ms with the primitive.
>> So it might be worth until you come with something better...
>>
>> For COG, the same bench goes from 65ms to 49ms, so the primitive is not
>> really necessary.
>> I'm pretty sure that Spur will change the numbers in favour of image-side
>> code.
>>
>
> Hmm, we need to be careful here.  Spur should speed up allocations, which
> include blocks, and at:put: on Arrays & Strings, etc, and garbage
> collection, but it doesn't speed up the basic execution engine.  So I doubt
> that it'll be any faster in Spur since the loop probably isn;t doing any
> allocations or at:put:'s, right?
>
> 2013/10/22 tim Rowledge <tim at rowledge.org>
>>
>>>
>>> On 22-10-2013, at 7:01 PM, commits at source.squeak.org wrote:
>>>
>>> > +     map := aFont characterToGlyphMap.
>>>
>>> Do we actually want this still? I know it is needed in terms of the ivar
>>> ordering, but that's a pity since it is a waste of time in all the cases I
>>> know about.
>>>
>>> It's almost certainly an improvement to get the prim running again, but
>>> overall I *think* we'd do better by adding a new prim to BitBltPlugin, to
>>> sit alongside the primitiveDisplayString (which I see also requires a
>>> characterToGlyphMap at the moment. That way the bitbltplugin effectively
>>> becomes our StrikeFont renderer in the same fashion as the FreeTypePlugin
>>> works for FreeType fonts.
>>>
>>> Has there ever been a case where that map was not effectively an
>>> identity map? I can see that there might be some appeal to mapping several
>>> characters to one glyph (like all non-printables to a null glyph) but has
>>> it ever been done that way?
>>>
>>> This ties in with the two mantis reports I mentioned last night -
>>> http://bugs.squeak.org/view.php?id=1372
>>> and
>>> http://bugs.squeak.org/view.php?id=1342
>>> since it would affect how we implement solutions.
>>>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> Is reading in the bathroom considered Multi-Tasking?
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131023/f2827c12/attachment.htm