[squeak-dev] Inefficiencies

Levente Uzonyi leves at elte.hu
Sat Sep 20 15:45:10 UTC 2014

I know it's an old thread, but I found this in my list of postponed 

If Color class >> #gray: were using #setRGB:, then most of the math could 
be avoided:

Color class >> #gray: brightness
 	"Return a gray shade with the given brightness in the range [0.0..1.0]."

 	^self basicNew setRGB: ((brightness * ComponentMax) rounded bitAnd: ComponentMask) * 1049601

ScrollBar >> #updateSliderColor: is strange, because it doesn't use its 
The GradientFillStyles created in #updateSliderColor: could be stored in 
the ScrollBar itself, instead of recreating them all the time.


On Thu, 24 Jul 2014, Bert Freudenberg wrote:

> While working on my SqueakJS VM (which now can run a current 4.5 image) I'm discovering a lot of gross inefficiencies. I have no time (or much desire) to fix these, but would anybody think it's valuable if I post them here? For example:
> ScrollBar>>initializeSlider
> ScrollBar>>sliderColor:
> ScrollBar>>updateSliderColor:
> Color class>>gray:
> Color>>setRed:green:blue:
> Float>>rounded
> Float>>sign
> Float>>>
> Number>>adaptToFloat:andCompare:
> Float>>asTrueFraction
> Integer>>bitOr:
> ctx[5]=rcvr: 3436915608L
> ctx[6]=tmp0: 16r10000000000000L
> ctx[7]=tmp1: nil
> Converting a Float to an exact Fraction just to find out its sign seems very much unnecessary. And without the LargeInteger primitive support it also is really really slow.
> My VM-level debugger makes it easy to stop at any time and look what's taking so long, so that's how I come across these.
> - Bert -

More information about the Squeak-dev mailing list