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 - smime.p7s (5K) Download Attachment |
+1
We can add #beginsWith: and #endsWith: in those string-related classes. :) Best, Marcel |
Ouch, ugly side effect of exact comparison... Should be fixed in: Kernel-nice.860Avoid engaging LargeInteger arithmetic (asTrueFraction) just for testing the sign of a Float 2014-07-24 12:05 GMT+02:00 Marcel Taeumel <[hidden email]>: +1 |
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 <[hidden email]>:
|
In reply to this post by Bert Freudenberg
> 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?
Definitely ! Stef |
In reply to this post by Bert Freudenberg
On Thu, Jul 24, 2014 at 4:41 AM, Bert Freudenberg <[hidden email]> 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: 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 |
In reply to this post by Bert Freudenberg
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 <[hidden email]> 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 - >> >> >> >> > smime.p7s (5K) Download Attachment |
Free forum by Nabble | Edit this page |