I was curious about the difference between sending duratinToRun and selecting an expression and doing "tally it", and the later presented a DNU, even attempting to tally "1 + 1"
-----Mensaje original----- De: [email protected] [mailto:[email protected]]en nombre de Henrik Johansen Enviado el: Viernes, 12 de Junio de 2009 09:11 a.m. Para: [email protected] Asunto: Re: [Pharo-project] Issue 832 I did some testing. During a minute of dragging/resizing windows (Class Browser, with 7-8 other windows in the background), the extra intersect happened approximately 6000 times. A small intersect speed test: a := Rectangle origin: 1...@1 corner: 1...@100. b := Rectangle origin: 3...@0 corner: 5 @ 50. [1000000 timesRepeat:[ a intersect: b]] durationToRun 0:00:00:00.992 So, about 6 ms overhead added over the course of a minute... Unless somehow there are Morphs which ends up redrawing MORE with a consistently SMALLER damage rect, I think it'd be wise to look elsewhere for any slowdowns experienced... Cheers, Henry Stéphane Ducasse skrev: > What is the status of that rollback? > Because if pahro get slower we should roll back > > Stef > On May 28, 2009, at 11:46 AM, Henrik Johansen wrote: > > >> Sure. >> I'd wait applying it till others can confirm that simply saving after >> running an update does not fix their performance problems though, as >> outlined in my last mail. >> >> Cheers, >> Henry >> >> Stéphane Ducasse skrev: >> >>> can you send me the st for the reverting? >>> >>> Stef >>> >>> On May 28, 2009, at 10:08 AM, Henrik Johansen wrote: >>> >>> >>> >>>> It's strange though, for me dragging is just as slow reverting the >>>> changes I made in a 319 image... >>>> And filing in the .st in a 309 image, I notice no slow downs. (309 >>>> upgraded to 319 I do). >>>> >>>> Are we sure nothing else causes this, perhaps changes related to >>>> events/polling frequency or something? >>>> >>>> Cheers, >>>> Henry >>>> >>>> Schwab,Wilhelm K skrev: >>>> >>>> >>>>> Henry, >>>>> >>>>> I for one appreciate your effort, and encourage you to keep going. >>>>> Speaking of slow machines, I have a small herd and would be willing >>>>> to >>>>> help you profile the problem. Give me about a month, and I will be >>>>> in >>>>> a position to press them into service to help with this. >>>>> >>>>> Bill >>>>> >>>>> >>>>> ---------------------------------------------------------------------- -- >>>>> *From:* [email protected] >>>>> [mailto:[email protected]] *On Behalf Of >>>>> *Henrik Sperre Johansen >>>>> *Sent:* Wednesday, May 27, 2009 5:07 PM >>>>> *To:* [email protected] >>>>> *Subject:* Re: [Pharo-project] Issue 832 >>>>> >>>>> Sorry, just back from the pub (YAY BARCELONA!) my initial reaction >>>>> was really: >>>>> I'd rather see the cause of such slowdowns while resizing >>>>> investigated >>>>> (and fixed), but considering the time needed to accomplish that, >>>>> rollbacking is probably a safer option at this time. >>>>> My mind absolutely boggles that a resizing performance decrease >>>>> would >>>>> be the most visible effect of the changes made in that update... >>>>> Welcome to the wonderful world of Morphic! >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> On 27.05.2009 23:54, Henrik Sperre Johansen wrote: >>>>> >>>>> >>>>>> Yes, rollbacking probably is the safest choice, >>>>>> As I implied in the mail, this was really meant as a experimental >>>>>> effort, to see if people on slower machines noticed the effects I >>>>>> was >>>>>> (pre)anticipating. >>>>>> I really don't see how an extra intersect: per Morph (containing >>>>>> submorphs) can make such a big difference... >>>>>> >>>>>> I'll definately post another update sometime in the future, I >>>>>> don't >>>>>> know when I'll have to look into it though. >>>>>> <rant> >>>>>> To me, the way it is right now seems unacceptable, there's >>>>>> really no >>>>>> reason to write a "smart" drawOn: routine for morphs that are >>>>>> likely >>>>>> to end up as a subMorph (saaaay, the TextMorph which I started >>>>>> investigating in the first place), as they have to redraw the >>>>>> entire >>>>>> area anyways. >>>>>> This leads to a bad cycle in morph development; >>>>>> "As long as at minimum the area we want to redraw is marked as, >>>>>> it's >>>>>> fine. There's no performance gain from reporting a more accurate >>>>>> area >>>>>> anyways". >>>>>> So you end up with "sloppy" damage rects for new morphs, which >>>>>> leads >>>>>> to more to fix if it IS changed, and slower performance for those >>>>>> whom redrawing the entire area rather than a subsection IS >>>>>> expensive. >>>>>> </rant> >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> >>>>>> On 27.05.2009 19:44, Stéphane Ducasse wrote: >>>>>> >>>>>> >>>>>>> Thanks for reporting. >>>>>>> Henrik? >>>>>>> I could rollback the changes. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Performance of UI seems poor after 832 integration. >>>>>>>> >>>>>>>> http://code.google.com/p/pharo/issues/detail?id=832 >>>>>>>> >>>>>>>> Regards, Gary >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- --- >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >> 'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 >> at 11:39:22 am'! >> >> !Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! >> drawSubmorphsOn: aCanvas >> "Display submorphs back to front" >> >> | drawBlock | >> submorphs isEmpty ifTrue: [^self]. >> drawBlock := [:canvas | submorphs reverseDo: [:m | canvas >> fullDrawMorph: m]]. >> self clipSubmorphs >> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] >> ifFalse: [drawBlock value: aCanvas]! ! >> >> >> !LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc >> 5/3/2006 14:27'! >> drawSubmorphsOn: aCanvas >> "Display submorphs back to front" >> >> |drawBlock i| >> submorphs isEmpty ifTrue: [^self]. >> drawBlock := [:canvas | >> (self topVisibleRowForCanvas: aCanvas) to: (self >> bottomVisibleRowForCanvas: aCanvas) do: [ :row | >> i := self item: row. >> canvas fullDrawMorph: i]]. >> self clipSubmorphs >> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] >> ifFalse: [drawBlock value: aCanvas]! ! >> >> >> !PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! >> drawSubmorphsOn: aCanvas >> "Display submorphs back to front, but skip my background sketch." >> >> | drawBlock | >> submorphs isEmpty ifTrue: [^self]. >> drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ >> backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. >> self clipSubmorphs >> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] >> ifFalse: [drawBlock value: aCanvas]! ! >> >> >> !TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc >> 5/31/2007 14:11'! >> drawSubmorphsOn: aCanvas >> "Display submorphs back to front. >> Draw the focus here since we are using inset bounds >> for the focus rectangle." >> >> super drawSubmorphsOn: aCanvas. >> self hasKeyboardFocus ifTrue: [ >> self selectedTab ifNotNilDo: [:t | >> self clipSubmorphs >> ifTrue: [aCanvas >> clipBy: self >> clippingBounds >> during: [:c | t >> drawKeyboardFocusOn: c]] >> ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! ! >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.524 / Virus Database: 270.12.11/2089 - Release Date: 30/04/2009 05:53 p.m. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
