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 -
+1
We can add #beginsWith: and #endsWith: in those string-related classes. :)
Best, Marcel
-- View this message in context: http://forum.world.st/Inefficiencies-tp4769793p4769812.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Ouch, ugly side effect of exact comparison...
Should be fixed in: Kernel-nice.860 Avoid engaging LargeInteger arithmetic (asTrueFraction) just for testing the sign of a Float
2014-07-24 12:05 GMT+02:00 Marcel Taeumel < marcel.taeumel@student.hpi.uni-potsdam.de>:
+1
We can add #beginsWith: and #endsWith: in those string-related classes. :)
Best, Marcel
-- View this message in context: http://forum.world.st/Inefficiencies-tp4769793p4769812.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Note that asTrueFraction is not engaged in classic VM nor cog/spur because the Float primitive for < > etc... do convert the SmallInteger parameter to Float, which apparently is not the case in your VM...
That makes me think that it will be a problem in 64 bits image with 61bits small int, because converting an int > 2^53 to double will be an inexact operation...
2014-07-24 13:02 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Ouch, ugly side effect of exact comparison...
Should be fixed in: Kernel-nice.860 Avoid engaging LargeInteger arithmetic (asTrueFraction) just for testing the sign of a Float
2014-07-24 12:05 GMT+02:00 Marcel Taeumel < marcel.taeumel@student.hpi.uni-potsdam.de>:
+1
We can add #beginsWith: and #endsWith: in those string-related classes. :)
Best, Marcel
-- View this message in context: http://forum.world.st/Inefficiencies-tp4769793p4769812.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Thu, Jul 24, 2014 at 4:41 AM, Bert Freudenberg bert@freudenbergs.de 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:
Oh man, we should _really_ take a look at those lower-level ones in the Number hierarchy. There could be some low-hanging cog-like-turbo-boost fruit lurking in there..
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 -
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 -
I *think* the gradient is stored in an LRUCache.
But still, it takes 5 Mbytecodes and 800 Ksends to open a browser, which seems a lot to me. I just did a
MessageTally tallySends: [Browser open]
which really gives a mind-boggling peak into what is happening.
- Bert -
On 20.09.2014, at 17:45, Levente Uzonyi leves@elte.hu wrote:
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 -
squeak-dev@lists.squeakfoundation.org