Traits approaching mainstream Squeak

Marcus Denker denker at iam.unibe.ch
Wed Aug 31 17:11:43 UTC 2005


Am 31.08.2005 um 18:47 schrieb Nick Brown:
> Performance in Squeak is important, but is there a general  
> performance problem with Squeak, or do newcomers get turned off  
> because one of the first things they get exposed to is Morphic,  
> which can in many ways feel slow? If I make a list of areas of  
> Squeak where I've found a performance problem (other than Morphic),  
> off the top of my head, I get: hashing in large collections,  
> CrLfFileStream; that's about it.
>

Morphic is improving... the "10-Browser" benchmark is now over 1.4  
times faster then in 3.8.

> I have no idea how much of a general performance impact there could  
> be by forcing so much state access through accessors, nor how much  
> of it could be regained by various means (I seem to recall somebody  
> suggests that the accessors could be inlined, but can't find the  
> message now). My feeling is that I would not worry very much about  
> a performance problem caused by traits until I can see it.

accessors are already a bit optimized: For the quickreturn methods  
the vm does not need to actually run the method, so no context is  
created. Activation thus
is cheap, of course the cost of method lookup still remains. But if  
the performance really turns out to be problem, I am sure that it  
won't be too hard to implement
just that performance relevant method in the classes, not the Trait.

And something that should be said again: Adding the possibility of  
using traits to squeak will *not* slow down any existing code at all.

      Marcus





More information about the Squeak-dev mailing list