Slow object printOn: with EURO symbol

> On 05 Jan 2016, at 13:08, Hilaire <[hidden email]> wrote:
>
> Le 04/01/2016 11:05, Henrik Johansen a écrit :
>> In the fallback code for WriteStream >> #nextPut:, at:put: is called,  so yes, streaming a wide char causes the streams collection to be converted from Byte to WideString.
>> Conversion is done using become, which currently triggers a full heap scan for references, and is thus very slow.
>> One could add a fast-path along the lines of #pastEndPut: (which has already broken any assumption that a reference to the collection will reflect all writes for the lifetime of stream, for the same performance problems one would face using #become:); if collection is a ByteString and anObject is a wide characters, replace collection with a WideString, and *then* call at:put:
>> But, it is not a very nice thing to add to a generic streaming class, nor is it a very attractive at this point in time considering that making become: a fast operation is one of the problems solved by Spur.
> So wait and see for Spur?
> To not forget about it, it is recorded here, and it should be kept open
> for later check:
> https://pharo.fogbugz.com/f/cases/17315/Slow-object-printOn-with-EURO-symbol
>
> It is  possible to turn around this problem, but this sort of annoyance
> with Pharo internal encoding regularly arises, so I am not sure what to
> think about the state of Pharo regarding internal encoding. Now days is
> not supposed to be all utf-8?
>
> Thanks
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

> 0450822759String with ByteString and WideString subclasses has been a standard feature of Squeak/Pharo for a long time. The transparent automatic conversion between the two is a feature, not a limitation.
>
> In se, there is nothing wrong with it.
>
> Yes, other representations of Strings are possible, but is is far from sure that they would be faster overall. The current implementation favours Latin1 (and thus ASCII), because that is so common. In my work image I count them as follows:
>
> ByteString allInstances size. "301498"
>
> WideString allInstances size. "136"
>
> That is less than 0.05%.
>
>> On 05 Jan 2016, at 13:08, Hilaire <[hidden email]> wrote:
>>
>> Le 04/01/2016 11:05, Henrik Johansen a écrit :
>>> In the fallback code for WriteStream >> #nextPut:, at:put: is called,  so yes, streaming a wide char causes the streams collection to be converted from Byte to WideString.
>>> Conversion is done using become, which currently triggers a full heap scan for references, and is thus very slow.
>>> One could add a fast-path along the lines of #pastEndPut: (which has already broken any assumption that a reference to the collection will reflect all writes for the lifetime of stream, for the same performance problems one would face using #become:); if collection is a ByteString and anObject is a wide characters, replace collection with a WideString, and *then* call at:put:
>>> But, it is not a very nice thing to add to a generic streaming class, nor is it a very attractive at this point in time considering that making become: a fast operation is one of the problems solved by Spur.
>> So wait and see for Spur?
>> To not forget about it, it is recorded here, and it should be kept open
>> for later check:
>> https://pharo.fogbugz.com/f/cases/17315/Slow-object-printOn-with-EURO-symbol
>>
>> It is  possible to turn around this problem, but this sort of annoyance
>> with Pharo internal encoding regularly arises, so I am not sure what to
>> think about the state of Pharo regarding internal encoding. Now days is
>> not supposed to be all utf-8?
>>
>> Thanks
>>
>> Hilaire
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>
>

> Hilaire
>
>
> Le 05/01/2016 13:20, Sven Van Caekenberghe a écrit :
>> 0450822759String with ByteString and WideString subclasses has been a standard feature of Squeak/Pharo for a long time. The transparent automatic conversion between the two is a feature, not a limitation.
>>
>> In se, there is nothing wrong with it.
>>
>> Yes, other representations of Strings are possible, but is is far from sure that they would be faster overall. The current implementation favours Latin1 (and thus ASCII), because that is so common. In my work image I count them as follows:
>>
>> ByteString allInstances size. "301498"
>>
>> WideString allInstances size. "136"
>>
>> That is less than 0.05%.
>>
>>> On 05 Jan 2016, at 13:08, Hilaire <[hidden email]> wrote:
>>>
>>> Le 04/01/2016 11:05, Henrik Johansen a écrit :
>>>> In the fallback code for WriteStream >> #nextPut:, at:put: is called,  so yes, streaming a wide char causes the streams collection to be converted from Byte to WideString.
>>>> Conversion is done using become, which currently triggers a full heap scan for references, and is thus very slow.
>>>> One could add a fast-path along the lines of #pastEndPut: (which has already broken any assumption that a reference to the collection will reflect all writes for the lifetime of stream, for the same performance problems one would face using #become:); if collection is a ByteString and anObject is a wide characters, replace collection with a WideString, and *then* call at:put:
>>>> But, it is not a very nice thing to add to a generic streaming class, nor is it a very attractive at this point in time considering that making become: a fast operation is one of the problems solved by Spur.
>>> So wait and see for Spur?
>>> To not forget about it, it is recorded here, and it should be kept open
>>> for later check:
>>> https://pharo.fogbugz.com/f/cases/17315/Slow-object-printOn-with-EURO-symbol
>>>
>>> It is  possible to turn around this problem, but this sort of annoyance
>>> with Pharo internal encoding regularly arises, so I am not sure what to
>>> think about the state of Pharo regarding internal encoding. Now days is
>>> not supposed to be all utf-8?
>>>
>>> Thanks
>>>
>>> Hilaire
>>>
>>> --
>>> Dr. Geo
>>> http://drgeo.eu
>>>
>>>
>>>
>>
>>
>
>
> --
> Dr. Geo
> http://drgeo.eu

> On Tue, Jan 5, 2016 at 10:20 PM, Hilaire <[hidden email]> wrote:
>> Le 05/01/2016 14:38, Sven Van Caekenberghe a écrit :
>>> The problem can does also be restated: it is really necessary for a tool to convert 1000s of items to strings, even if only 10s are shown at the same time on a screen ?
>>>
>>> I believe that fast table tries to do better here.
>> But I need to show 1000s of them once, all in the same view, at the same
>> time.
> Is it that the same 1000 strings are being rendered multiple times a
> second?  I had a similar problem with Roassal 1 with a unicode char
> massively slowing down to UI.  I managed to achieve fairly normal
> response time by cached the Freetype calculated width of the string.
> I found the right place to do this by both profiling the whole system,
> and just the rendering by wrapping MessaeTally around the code of
> fullDrawOn: .
>
> Then I cache both the string and its calculated length from the
> rendering code, then if the cached string is the same as current I
> just returned the cached length.
>
> Sorry I can't be clearer.
> cheers -ben
>
>