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

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 
argument.
The GradientFillStyles created in #updateSliderColor: could be stored in 
the ScrollBar itself, instead of recreating them all the time.


Levente

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 -
>
>
>
>