[Pharo-project] about Issue 860: Accelerate MulitByteFileStream
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
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
2009/11/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Henrik Johansen -
Nicolas Cellier -
Stéphane Ducasse