On Wed, Oct 23, 2013 at 5:51 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> Ah, no, I was thinking that String>>at: and asciiValue would be accelerated
>
>
>             char := sourceString at: lastIndex.
>             ascii := char asciiValue + 1.
>

Oops, I'd forgotten that :-),  You're right, that should make some
difference.


>
>
> 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
>>
>>
>>
>>
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131023/60aafd7c/attachment.htm