2009/2/8 Stéphane Ducasse <[email protected]>: >> >>> Igor could you give us the snippets for the benchmarks. >>> I would like to use them as example for a forthcoming chapter on >>> profiling. >>> >> >> What exactly snippets you want? > > the one where you create the button and how you measure it :)
heh.. why i should care to create a button, when i got plenty of them on the screen? :) i simply clicking through morphs until i got button morph halo, and then doing 'inspect morph'. the rest is then trivial, in inspector window you can send any messages to this morph, like: self drawOn: World assuredCanvas. ;) > >> >> I'm using most simple ways to measure performance, including: >> >> [ .... ] timeToRun. >> or >> MessageTally spyOn: [...] >> >> i made a simple class GlobalCounter >> >> to use a >> GlobalCounter increment: 'some id' >> >> in methods i'm interested in and then run some code like following: >> >> GlobalCounter reset. >> mycode run. >> GlobalCounter counters copy "inspect" >> >> GlobalCounter implementation is trivial, i don't think it requires any >> explanation how it works :) >> >>> Stef >>> >>> On Feb 8, 2009, at 2:55 PM, Igor Stasenko wrote: >>> >>>> I'm also want to play with rounding and compare the efficiency of >>>> drawing an initially rounded shape (by using curves) instead of >>>> hacking , which CornerRounder does. >>>> >>>> I took a single rounded button and measured how fast it get drawn >>>> and >>>> what parts of drawing process takes what time: >>>> >>>> 100 times >>>> - fulldraw 80ms >>>> - (1) draw 18ms (simple fill a rectangle) >>>> - (2) fulldraw w/o rounding 51ms (almost same as a fulldraw but w/o >>>> use of CorderRounder) >>>> >>>> so, CornerRounder takes 30ms for itself (from total 80ms). >>>> I think if we initially draw a rounded shape, we could have better >>>> numbers , i hoping that drawing a filled rectangular shape and >>>> filled >>>> rounded rectangular shape could have much less difference (much less >>>> than 30ms). >>>> It's a bit expensive to spend 3/8 of total rendering time for such >>>> little fancy thing :) >>>> >>>> 2009/2/8 Igor Stasenko <[email protected]>: >>>>> 2009/2/8 Gary Chambers <[email protected]>: >>>>>> I'll make the drop shadows themable for system windows. >>>>>> The default way Morphic does drop shadows is quite inefficient. >>>>>> >>>>> >>>>> Right, i think it would be wise to provide own implementation of >>>>> drawDropShadowOn: for SystemWindow, to draw simple rectangle (or >>>>> group >>>>> of rectangles to avoid excessive fills) since we know that >>>>> systemwindow is rectangular beforehead. >>>>> >>>>> >>>>>> Regards, Gary >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Igor Stasenko" <[email protected]> >>>>>> To: <[email protected]> >>>>>> Sent: Saturday, February 07, 2009 7:23 PM >>>>>> Subject: Re: [Pharo-project] Call for UI gripes >>>>>> >>>>>> >>>>>>> 2009/2/7 Ramon Leon <[email protected]>: >>>>>>>>> The biggest concern I have right now is speed. I'm not >>>>>>>>> saying Pharo is too slow; I'm simply admitting that I do not >>>>>>>>> know whether it is fast enough for some of the things I want to >>>>>>>>> do. >>>>>>>> >>>>>>>> +10 to this. >>>>>>>> >>>>>>>> The UI is looking really great lately, but overall the >>>>>>>> experience is it's >>>>>>>> just too slow. Cracking open a raw squeak base image reminds me >>>>>>>> how >>>>>>>> snappy >>>>>>>> the UI used to be. Not really complaining, it's totally >>>>>>>> bearable, but >>>>>>>> it'd >>>>>>>> sure be nice if the pretty UI was quick and snappy, and you are >>>>>>>> asking. >>>>>>>> >>>>>>> Sure thing >>>>>>> MessageTally spyOn:[self fullDrawOn: World assuredCanvas] "where >>>>>>> self >>>>>>> is an OB system window morph" >>>>>>> >>>>>>> 16.7% {10ms} BalloonEngine>>copyLoopFaster >>>>>>> 11.7% {7ms} SimpleBorder>>frameRectangle:on: >>>>>>> 6.7% {4ms} Array(SequenceableCollection)>>select: >>>>>>> 5.0% {3ms} ByteString(String)>>= >>>>>>> 5.0% {3ms} SmallInteger(Number)>>to:by:do: >>>>>>> 5.0% {3ms} >>>>>>> GrafPort(BitBlt)>>primDisplayString:from:to:map:xTable:kern: >>>>>>> 5.0% {3ms} BorderStyle>>frameRectangle:on: >>>>>>> 3.3% {2ms} ByteSymbol>>species >>>>>>> 3.3% {2ms} ByteString class(String class)>>new: >>>>>>> >>>>>>> total 61ms. >>>>>>> >>>>>>> some hot points crying to be optimized: >>>>>>> cache the OBMonticelloPackageNode>>classCategories , which get >>>>>>> rebuilt each time you draw the window. >>>>>>> this can make following numbers much smaller: >>>>>>> 5.0% {3ms} ByteString(String)>>= >>>>>>> 6.7% {4ms} Array(SequenceableCollection)>>select: >>>>>>> 3.3% {2ms} ByteString class(String class)>>new: >>>>>>> >>>>>>> Making SystemWindow>>drawDropShadowOn: to do nothing makes a >>>>>>> difference: >>>>>>> >>>>>>> [10 timesRepeat: [self fullDrawOn: World assuredCanvas ]] >>>>>>> timeToRun >>>>>>> with shadows: 530 >>>>>>> without: 473 >>>>>>> ~ 10% speedup >>>>>>> >>>>>>> Changing the theme makes some difference (no shadows/with >>>>>>> shadows): >>>>>>> - Watery 2: 50/60 ms >>>>>>> - Standard Squeak: 38/43 ms >>>>>>> - Soft Squeak: 46/55 ms >>>>>>> - Vistary: 56/62ms >>>>>>> (keep in mind these numbers are polluted with messageTally) >>>>>>> >>>>>>> As to me, the theme variancy is quite acceptable - a most complex >>>>>>> theme (with transulency) is drawn just 50% slower than most >>>>>>> simple >>>>>>> one. >>>>>>> >>>>>>> As for, >>>>>>> 3.3% {2ms} ByteString class(String class)>>new: >>>>>>> >>>>>>> Total count of ByteString>>new: calls during >>>>>>> GlobalCounter reset. >>>>>>> self fullDrawOn: World assuredCanvas. >>>>>>> GlobalCounter counters copy inspect >>>>>>> >>>>>>> is 7146, >>>>>>> which again makes me look suspicious at OB here.. Hey! Are we >>>>>>> drawing, >>>>>>> or processing a text?!?! >>>>>>> >>>>>>> >>>>>>>> Ramon Leon >>>>>>>> http://onsmalltalk.com >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>>>> project >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [email protected] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [email protected] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>> project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <GlobalCounter.st>_______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
