On 05 Jan 2016, at 14:26, Hilaire <hilaire@drgeo.eu> wrote:
Agree. Nevertheless, the performance impact I got on OOP way of doing things can't be wiped out: when you ask an object to give its text representation but use non latin1 character, you get an important penalty. In the long term, it looks like a problem for Pharo.
No, that is not 100% correct. You can use any Unicode anywhere tranparantly and the performance penalty is low. Pharo supports Unicode everywhere for 100% (given you use the right font). The problem occurs only when you take a collection of 1000s of these objects in a tool that wants to convert them all at once but separately to strings. Then the cumulative performance penalty becomes quite noticeable, true. 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.
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 <hilaire@drgeo.eu> 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