Thanks Herbert for tip on timing.

For interest I tried. The results were.

Squeak 5600 - 5800 milliseconds Pharo 5400 - 5500 milliseconds Cuis 200 - 500 milliseconds

So there was a factor of 10 in it which I why I noticed I guess.

2009/11/12 Herbert König herbertkoenig@gmx.net

Hi John,

JW> Absolute beginner playing with smalltalk. I have a simple JW> program that opens a number of text files, plays with data closes JW> files and gives a count of things in the files. (Its actually my JW> Squeak version of the Cincom VW Tutorial). I have run it on JW> Squeak, Pharo and Cuis images. What suprised me was the difference JW> in speeds. I haven't done tried to time it (I should do that or

in case you don't know how: Time millisecondsToRun: [your code goes here] returns what it says.

JW> at least work out how to) but Squeak and Pharo take about the same JW> time whereas Cuis is significantly quicker. I know its a cut down JW> image but the difference is remarkable. Is this to be expected?

If you talk about files, a significant part of the time might be spent in the OS which depends on cacheing.

So unless there is significant processing, file access might dominate (and invalidate) the measured times.

Cuis has removed and cleaned up things which tends to speed things up but usually not to a noticeable degree. Even if you hit a significantly sped up method, such results should not be generalized.

Cuis is not advertised for higher speed but for cleaner code, less bulk and better looks. IMHO that is.

-- Cheers,

Herbert

---

Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

Herbert,

I will email you the file and the data files its reading. If there is something of interest to others you can then post up the part matters.

John

2009/11/14 Herbert König herbertkoenig@gmx.net

Hi John,

JW> For interest I tried. The results were.

JW> Squeak 5600 - 5800 milliseconds JW> Pharo 5400 - 5500 milliseconds JW> Cuis 200 - 500 milliseconds

JW> So there was a factor of 10 in it which I why I noticed I guess.

this is significant so I'm very curious what accounts for the difference. Would you mind to send me the Squeak version or post it here?

-- Cheers,

Herbert

---

Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

So are you saying that my example is slow because of the time taken to process the text data files in Squeak? (I was using 3.10)

Not that it matters in this case but how would I work around this if it were a real application that needed to handle data in this way?

John

2009/11/15 Herbert König herbertkoenig@gmx.net

John,

JW> I will email you the file and the data files its reading. If

thanks.

JW> there is something of interest to others you can then post up the JW> part matters.

I used TimeProfileBrowser (as Subbu suggested) and Squeak 3.8.2 (supporting UTF8) in comparison to Squeak 3.6 (which is pre Cuis).

As Bert suggested, in more recent Squeaks a lot of time is spent in UTF8 decoding. My figures are 9300ms (3.8) vs. 480ms (3.6).

In 3.6 significant time is spent in displaying the results on the Transcript. If I comment out that line in getLogFiles I'm down to 312ms.

Which again shows the value of profiling before optimizing :-))

For unknown reasons in Cuis FileDirectory>>fileNames returns an empty Array so I can't try there.

Cheers,

Herbert

---

Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 14.11.2009, at 23:07, John Worden wrote:

So are you saying that my example is slow because of the time taken to process the text data files in Squeak? (I was using 3.10)

Not that it matters in this case but how would I work around this if it were a real application that needed to handle data in this way?

John

If you do, e.g.,

FileStream readOnlyFileNamed: myFileName

it creates a MultiByteFileStream nowadays (see #concreteStream). It would be nice if we could just set a no-op converter in a MultiByteFileStream. However, that class has not been optimized for speed yet, even without an expensive converter it is much slower. It reads characters one-by-one instead of block-wise, which obviously isn't speedy exactly, as you noticed.

Instead of the abstract FileStream use the stream class you want explicitly. StandardFileStream is the old class that does no conversion. So you would open your file like this instead:

StandardFileStream readOnlyFileNamed: myFileName

- Bert -

I made the changes suggested by Bert and used StandardFileStream. Yes it fixes the speed issue.

As I said previously this has been interesting but it does leave me with mixed feelings which while off topic Ill express. As I said at the start of this I am a beginner. I can write a simple program and make it work and have done (PHP/Python/VisBasic/VBA).

I came to Squeak/Smalltalk and started having a play. There is something addictive about it but at the same time there are things like the speed issue above that don't make it "easy" for the learner. As an exercise I started to convert the excellent Cincom VW Tutorial to work in Squeak and at the same time I was converting it into Python. End result is that I had less difficulty getting it to work in Python than simply converting to Squeak. I wasn't expecting that. (For interest the other big problem I had, in addition to the speed one, was with the CrLf handling)

I am *not* trying to compare one language to another. Neither is it a judgement call on whats right or wrong all have their fit I'm sure. My question is whether people feel Squeak really is suitable for someone who just enjoys scripting simple programs? I can see the value in it from an educational perspective but for someone like me (who to be honest doesn't even want to worry about what things like UTF8 Support are all about) is it a good choice?

John

On Mon, Nov 16, 2009 at 8:26 AM, John Worden worden.john@gmail.com wrote:

Thanks to all.

Interesting and educational.

John

On Mon, Nov 16, 2009 at 12:17 AM, Bert Freudenberg bert@freudenbergs.dewrote:

...

On 14.11.2009, at 23:07, John Worden wrote:

...

So are you saying that my example is slow because of the time taken to

process the text data files in Squeak? (I was using 3.10)

...

Not that it matters in this case but how would I work around this if it

were a real application that needed to handle data in this way?

...

John

If you do, e.g.,

   FileStream readOnlyFileNamed: myFileName

it creates a MultiByteFileStream nowadays (see #concreteStream). It would be nice if we could just set a no-op converter in a MultiByteFileStream. However, that class has not been optimized for speed yet, even without an expensive converter it is much slower. It reads characters one-by-one instead of block-wise, which obviously isn't speedy exactly, as you noticed.

Instead of the abstract FileStream use the stream class you want explicitly. StandardFileStream is the old class that does no conversion. So you would open your file like this instead:

   StandardFileStream readOnlyFileNamed: myFileName

• Bert -

---

Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Monday 16 November 2009 07:07:56 am John Worden wrote:

My question is whether people feel Squeak really is suitable for someone who just enjoys scripting simple programs?

Squeak is a scripting environment and there are many people who enjoy scripting in it, so if you are asking for a possibility the answer is Yes.

But the choice is very personal and depends on your approach to solving problems. Smalltalk does not have any layers/barriers and allows one to 'tinker' freely. I also learnt (the hard way :-() that Squeak cannot be learnt easily from books because of their linear presentation styles. The best way to learn Squeak is to adopt a lateral, non-linear (as in Chess) and use Squeak itself as a living book.

BTW, the fact that you were able to drill down to a specific performance bottleneck so quickly shows the power of Squeak.

Subbu

At Sun, 15 Nov 2009 14:17:41 +0100, Bert Freudenberg wrote:

Instead of the abstract FileStream use the stream class you want explicitly. StandardFileStream is the old class that does no conversion. So you would open your file like this instead:

StandardFileStream readOnlyFileNamed: myFileName

Alternatively, if it is reading the entire file knowing that it is not encoded, you can say:

(FileStream readOnlyFileNamed: myFileName) binary contentsOfEntireFile asString

-- Yoshiki