about Issue 860: Accelerate MulitByteFileStream

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

about Issue 860: Accelerate MulitByteFileStream

Stéphane Ducasse

nicolas

do you have an idea how I could integrate these changes. I could not  
really understand what
andreas meant when he pushed them into their trunk

Stef





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about Issue 860: Accelerate MulitByteFileStream

Nicolas Cellier
Hi Stephane,

I just repeated the work in four steps, it worked OK in my Pharo image.
You just have to publish a package and a ScriptLoader script after
each changeSet.
Andreas managed to load in fewer steps, but he had modified Monticello
load order previously.
No need to be that adventurous.

Nicolas

2009/11/1 Stéphane Ducasse <[hidden email]>:

>
> nicolas
>
> do you have an idea how I could integrate these changes. I could not
> really understand what
> andreas meant when he pushed them into their trunk
>
> Stef
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about Issue 860: Accelerate MulitByteFileStream

Stéphane Ducasse
excellent I do that now.

Stef

On Nov 1, 2009, at 9:08 PM, Nicolas Cellier wrote:

> Hi Stephane,
>
> I just repeated the work in four steps, it worked OK in my Pharo  
> image.
> You just have to publish a package and a ScriptLoader script after
> each changeSet.
> Andreas managed to load in fewer steps, but he had modified Monticello
> load order previously.
> No need to be that adventurous.
>
> Nicolas
>
> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>>
>> nicolas
>>
>> do you have an idea how I could integrate these changes. I could not
>> really understand what
>> andreas meant when he pushed them into their trunk
>>
>> Stef
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about Issue 860: Accelerate MulitByteFileStream

Stéphane Ducasse
In reply to this post by Nicolas Cellier
when you I invoke the magic expression
        SourceFiles do: [:e | (e isKindOf: MultiByteFileStream) ifTrue: [
                e installLineEndConventionInConverter]]
I will read you changes to try to understand and learn something  
today :)


On Nov 1, 2009, at 9:08 PM, Nicolas Cellier wrote:

> Hi Stephane,
>
> I just repeated the work in four steps, it worked OK in my Pharo  
> image.
> You just have to publish a package and a ScriptLoader script after
> each changeSet.
> Andreas managed to load in fewer steps, but he had modified Monticello
> load order previously.
> No need to be that adventurous.
>
> Nicolas
>
> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>>
>> nicolas
>>
>> do you have an idea how I could integrate these changes. I could not
>> really understand what
>> andreas meant when he pushed them into their trunk
>>
>> Stef
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about Issue 860: Accelerate MulitByteFileStream

Stéphane Ducasse
In reply to this post by Nicolas Cellier
Nicolas

I was wondering why TextConverter>> initialize
was calling nextPut: to Stream: which is abstract.

So I imagine that only subclasses are invoking this behavior.

So I was trying to understand the speed up idea but I failed (because  
I did not know the speed up of andreas).

Stef



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about Issue 860: Accelerate MulitByteFileStream

Nicolas Cellier
2009/11/1 Stéphane Ducasse <[hidden email]>:
> Nicolas
>
> I was wondering why TextConverter>> initialize
> was calling nextPut: to Stream: which is abstract.
>

which initialize ?
initializeLatin1MapAndEncodings ? yes, it is intended for concrete
subclass only and triggered by lazy initialization.

> So I imagine that only subclasses are invoking this behavior.
>
> So I was trying to understand the speed up idea but I failed (because
> I did not know the speed up of andreas).
>
> Stef
>
>

MultiByteFileStream iterate Character by Character which is sloooow...
The idea is that most ASCII characters won't need a conversion.
Andreas trick is to do a fast scan of the String for detecting chunks
not requiring translation
(there are fast primitives to do that on a ByteString).
This enables putting these chunks of String without translations
directly on the stream...

I generalized this to any format (not only UTF8)
I generalized this to lineEndConventions (for converting CR/LF,
MultiByteFileStream iterates char by char too)

That's for writting only. Maybe someday we should also speed reading up.

Nicolas

>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about Issue 860: Accelerate MulitByteFileStream

Stéphane Ducasse
Thanks I will reread the code to understand

On Nov 1, 2009, at 11:06 PM, Nicolas Cellier wrote:

> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>> Nicolas
>>
>> I was wondering why TextConverter>> initialize
>> was calling nextPut: to Stream: which is abstract.
>>
>
> which initialize ?
> initializeLatin1MapAndEncodings ? yes, it is intended for concrete
> subclass only and triggered by lazy initialization.
>
>> So I imagine that only subclasses are invoking this behavior.
>>
>> So I was trying to understand the speed up idea but I failed (because
>> I did not know the speed up of andreas).
>>
>> Stef
>>
>>
>
> MultiByteFileStream iterate Character by Character which is sloooow...
> The idea is that most ASCII characters won't need a conversion.
> Andreas trick is to do a fast scan of the String for detecting chunks
> not requiring translation
> (there are fast primitives to do that on a ByteString).
> This enables putting these chunks of String without translations
> directly on the stream...
>
> I generalized this to any format (not only UTF8)
> I generalized this to lineEndConventions (for converting CR/LF,
> MultiByteFileStream iterates char by char too)
>
> That's for writting only. Maybe someday we should also speed reading  
> up.
>
> Nicolas
>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: about Issue 860: Accelerate MulitByteFileStream

Henrik Sperre Johansen
In reply to this post by Nicolas Cellier
Sounds like the same kind of change I did to Strike Font character  
rendering :)

Might want to check if the method hasWideCharactersFrom:to: I  
implemented for Strings/Text might be of use to clarify the code intent.
(See StrikeFont >> displayString:on:from:to:at:kern: for an example  
usage)

Cheers,
Henry


On Nov 1, 2009, at 11:06 43PM, Nicolas Cellier wrote:

> 2009/11/1 Stéphane Ducasse <[hidden email]>:
>> Nicolas
>>
>> I was wondering why TextConverter>> initialize
>> was calling nextPut: to Stream: which is abstract.
>>
>
> which initialize ?
> initializeLatin1MapAndEncodings ? yes, it is intended for concrete
> subclass only and triggered by lazy initialization.
>
>> So I imagine that only subclasses are invoking this behavior.
>>
>> So I was trying to understand the speed up idea but I failed (because
>> I did not know the speed up of andreas).
>>
>> Stef
>>
>>
>
> MultiByteFileStream iterate Character by Character which is sloooow...
> The idea is that most ASCII characters won't need a conversion.
> Andreas trick is to do a fast scan of the String for detecting chunks
> not requiring translation
> (there are fast primitives to do that on a ByteString).
> This enables putting these chunks of String without translations
> directly on the stream...
>
> I generalized this to any format (not only UTF8)
> I generalized this to lineEndConventions (for converting CR/LF,
> MultiByteFileStream iterates char by char too)
>
> That's for writting only. Maybe someday we should also speed reading  
> up.
>
> Nicolas
>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project