Hello list,
I've been using Damien's dev images, and specifically the beta-web (sq3.10-7121web07.07.01, although it has been upgraded), and I've noticed that it has been getting slower over time. By "slower", I mean the responsiveness of the tools. I have to click multiple times to select items in OmniBrowser or in the Debug windows. My web application is still as speedy as ever, so it doesn't seem like a general slowdown. I'm not using Dynamic Protocols, because they were very slow, but after turning them off, the image was very responsive. I recall someone mentioning in passing a cache somewhere that could be cleaned out, but I can't remember enough to search successfully for the reference :) Any suggestions would be welcome! - Brian |
2007/9/20, Brian Brown <[hidden email]>:
> I've been using Damien's dev images, and specifically the beta-web > (sq3.10-7121web07.07.01, although it has been upgraded), and I've > noticed that it has been getting slower over time. By "slower", I > mean the responsiveness of the tools. I have to click multiple times > to select items in OmniBrowser or in the Debug windows. My web > application is still as speedy as ever, so it doesn't seem like a > general slowdown. > > I'm not using Dynamic Protocols, because they were very slow, but > after turning them off, the image was very responsive. I do not understand. Is your image still slow after having deactivated DynamicProtocols? > I recall someone mentioning in passing a cache somewhere that could > be cleaned out, but I can't remember enough to search successfully > for the reference :) I think this was about dynamic protocols too. You can try: DynamicProtocols invalidateCache I'm really waiting for someone who can have a look at OmniBrowser, see why it is slow and improve it. -- Damien Cassou |
I had the same problem, needing to click several times to actually have a click. It was actually a morphic problem.
I executed: Utilities cleanseOtherworldlySteppers and things went back to normal. Romain On Sep 20, 2007, at 5:17 PM, Damien Cassou wrote:
-- Romain Robbes |
> I had the same problem, needing to click several times to actually have a
> click. It was actually a morphic problem. I found that some versions of OB included logging of all announcements to the transcript. Removing that line (I think it is not in there anymore in more recent versions) made everything go much faster. Lukas -- Lukas Renggli http://www.lukas-renggli.ch |
2007/9/20, Lukas Renggli <[hidden email]>:
> > I had the same problem, needing to click several times to actually have a > > click. It was actually a morphic problem. > > I found that some versions of OB included logging of all announcements > to the transcript. Removing that line (I think it is not in there > anymore in more recent versions) made everything go much faster. I removed that line, right. Please upgrade to a more recent version and see if it's better. -- Damien Cassou |
In reply to this post by Lukas Renggli
I've noticed that, even with dynamic protocols off, the OB is really
slow when looking at big classes like Object. Trying to scroll down the method list is very frustrating. I've made system windows activate themselves when I roll over them. That is also affected by OB, although I don't know why. When I have an OB open to Object and then roll to another window, that window activation happens very slowly. When I move OB off Object, window activation is much faster again. That said, it's a great browser. Mike On 9/20/07, Lukas Renggli <[hidden email]> wrote: > > I had the same problem, needing to click several times to actually have a > > click. It was actually a morphic problem. > > I found that some versions of OB included logging of all announcements > to the transcript. Removing that line (I think it is not in there > anymore in more recent versions) made everything go much faster. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > |
In reply to this post by Romain Robbes-2
I've
had similar problems with steppers, also lurking TransferMorphs can lead to
unexpected slowdowns...
|
In reply to this post by Lukas Renggli
Hey Romain, I owe you a beer :)
Things are much better now, and in the Transcript it printed: 1 morphs removed from steplist. Lukas, Are you talking about the OBBrowser>>transcribe method? Thank you, - Brian On Sep 20, 2007, at 9:58 AM, Lukas Renggli wrote: >> I had the same problem, needing to click several times to actually >> have a >> click. It was actually a morphic problem. > > I found that some versions of OB included logging of all announcements > to the transcript. Removing that line (I think it is not in there > anymore in more recent versions) made everything go much faster. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > |
> Lukas,
> > Are you talking about the OBBrowser>>transcribe method? #transcribe is normally not called, I assume it is there for debugging purpose only. The transcript statement that got registered and caused a major slowdown in my images was in #subscribe itself. Lukas -- Lukas Renggli http://www.lukas-renggli.ch |
In reply to this post by Brian Brown-2
2007/9/20, Brian Brown <[hidden email]>:
> Are you talking about the OBBrowser>>transcribe method? Yes, this method should not been called anymore. -- Damien Cassou |
In reply to this post by Brian Brown-2
On Thu, 2007-09-20 at 08:59 -0600, Brian Brown wrote: > Hello list, > > I've been using Damien's dev images, and specifically the beta-web > (sq3.10-7121web07.07.01, although it has been upgraded), and I've > noticed that it has been getting slower over time. By "slower", I > mean the responsiveness of the tools. I have to click multiple times > to select items in OmniBrowser or in the Debug windows. My web > application is still as speedy as ever, so it doesn't seem like a > general slowdown. > > I'm not using Dynamic Protocols, because they were very slow, but > after turning them off, the image was very responsive. > > I recall someone mentioning in passing a cache somewhere that could > be cleaned out, but I can't remember enough to search successfully > for the reference :) > > but collected some lines which might help. The first is a collection of cleanup tasks. I think I stole it from Ramon. garbageCollect | tasks | tasks := OrderedCollection new add: [MCFileBasedRepository flushAllCaches]; add: [WARegistry clearAllHandlers]; add: [SMSqueakMap default clearCaches]; add: [Smalltalk removeEmptyMessageCategories]; add: [Workspace allSubInstancesDo: [:each | each setBindings: Dictionary new]]; add: [Undeclared removeUnreferencedKeys]; add: [Categorizer sortAllCategories]; add: ["add: [ODBCConnection cleanAll];" Symbol compactSymbolTable]; add: [ReleaseBuilderDeveloper new fixObsoleteReferences]; add: [Smalltalk garbageCollectMost]; yourself. Utilities informUserDuring: [:bar | tasks do: [:block | bar value: block printString. [block value] on: Error do: [:error | Transcript show: error; cr]]]. SystemNavigation default obsoleteClasses isEmpty ifTrue: [SmalltalkImage current saveSession] ifFalse: [SystemNavigation default obsoleteClasses do: [:each | [PointerFinder on: each] on: Error do: [:error | Transcript show: error; cr]]] If you have a big image it could use some time to complete. Working with the dev-image I discovered some problems with a slow image. I collected some measures using the pointer finder. I don't know if they are doing any harm but they help :) Dialect reset. "I'm using Glorp" RequiredSelectors initialize. DPAbstract allSubclasses do: [:each| each invalidateCache]. TestResultTimed resetLastResults. EventManager actionMaps keys do: [:each| EventManager releaseActionMapFor: each]. It is a good idea to invoke those before using the garbageCollect task. Hope this helps., Norbert |
2007/9/20, Norbert Hartl <[hidden email]>:
> DPAbstract allSubclasses do: [:each| each invalidateCache]. which is equivalent to: DynamicProtocol invalidateCache -- Damien Cassou |
In reply to this post by Michael Fremont
On 20/09/2007, Michael Fremont <[hidden email]> wrote:
> I've noticed that, even with dynamic protocols off, the OB is really > slow when looking at big classes like Object. Trying to scroll down > the method list is very frustrating. > Such behavior indicates that there is something wrong with List(or PluggableList) morph, which thinks that its not clipped and trying rendering all items, instead of those, which you can actually see. Of course, its only a suggestion. > I've made system windows activate themselves when I roll over them. > That is also affected by OB, although I don't know why. When I have > an OB open to Object and then roll to another window, that window > activation happens very slowly. When I move OB off Object, window > activation is much faster again. > > That said, it's a great browser. > > Mike > > On 9/20/07, Lukas Renggli <[hidden email]> wrote: > > > I had the same problem, needing to click several times to actually have a > > > click. It was actually a morphic problem. > > > > I found that some versions of OB included logging of all announcements > > to the transcript. Removing that line (I think it is not in there > > anymore in more recent versions) made everything go much faster. > > > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > > > -- Best regards, Igor Stasenko AKA sig. |
Igor Stasenko a écrit :
> On 20/09/2007, Michael Fremont <[hidden email]> wrote: > >> I've noticed that, even with dynamic protocols off, the OB is really >> slow when looking at big classes like Object. Trying to scroll down >> the method list is very frustrating. >> >> > Such behavior indicates that there is something wrong with List(or > PluggableList) morph, which thinks that its not clipped and trying > rendering all items, instead of those, which you can actually see. > Of course, its only a suggestion. > displayed in the method list...Basically, I think there is a full lookup at all methods and not only those that are visible (is it easily changeable ?). This slow display basically occurs in Object which is easy to understand. I added some otherkind of Icons (call super and other stuff) and this was terribly slow.... Either we could desactivate OBIcon for Object (not optimal but easy) or adopt another Icon mapping strategy ? Cédrick |
2007/9/21, Cédrick Béler <[hidden email]>:
> Something like that... Browsing Objects is slow since icons are > displayed in the method list...Basically, I think there is a full lookup > at all methods and not only those that are visible (is it easily > changeable ?). This slow display basically occurs in Object which is > easy to understand. I added some otherkind of Icons (call super and > other stuff) and this was terribly slow.... Either we could desactivate > OBIcon for Object (not optimal but easy) or adopt another Icon mapping > strategy ? Icons are cool but they are really like DynamicProtocols which proved to be slow. Having both of them is really too slow. I think we need both, but everything has to be optimized. -- Damien Cassou |
I just vent to OB window and came deep to inspect the instance of
OBLazyListMorph do: self drawOn: Display getCanvas and watch how slow its rendering! With Object class selected: [self drawOn: Display getCanvas ] timeToRun 7887 On 21/09/2007, Damien Cassou <[hidden email]> wrote: > 2007/9/21, Cédrick Béler <[hidden email]>: > > Something like that... Browsing Objects is slow since icons are > > displayed in the method list...Basically, I think there is a full lookup > > at all methods and not only those that are visible (is it easily > > changeable ?). This slow display basically occurs in Object which is > > easy to understand. I added some otherkind of Icons (call super and > > other stuff) and this was terribly slow.... Either we could desactivate > > OBIcon for Object (not optimal but easy) or adopt another Icon mapping > > strategy ? > > > Icons are cool but they are really like DynamicProtocols which proved > to be slow. Having both of them is really too slow. I think we need > both, but everything has to be optimized. > > -- > Damien Cassou > > > > -- Best regards, Igor Stasenko AKA sig. |
What can we do? Do you have some time to help improving this situation?
2007/9/21, Igor Stasenko <[hidden email]>: > I just vent to OB window and came deep to inspect the instance of > OBLazyListMorph > do: > self drawOn: Display getCanvas > > and watch how slow its rendering! > > With Object class selected: > [self drawOn: Display getCanvas ] timeToRun 7887 > > > On 21/09/2007, Damien Cassou <[hidden email]> wrote: > > 2007/9/21, Cédrick Béler <[hidden email]>: > > > Something like that... Browsing Objects is slow since icons are > > > displayed in the method list...Basically, I think there is a full lookup > > > at all methods and not only those that are visible (is it easily > > > changeable ?). This slow display basically occurs in Object which is > > > easy to understand. I added some otherkind of Icons (call super and > > > other stuff) and this was terribly slow.... Either we could desactivate > > > OBIcon for Object (not optimal but easy) or adopt another Icon mapping > > > strategy ? > > > > > > Icons are cool but they are really like DynamicProtocols which proved > > to be slow. Having both of them is really too slow. I think we need > > both, but everything has to be optimized. > > > > -- > > Damien Cassou > > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > > -- Damien Cassou |
In reply to this post by Igor Stasenko
Perhaps we need a OBHardWorkingListMorph that can get the job done a
little faster then. :-) On Sep 21, 2007, at 8:11 AM, Igor Stasenko wrote: > I just vent to OB window and came deep to inspect the instance of > OBLazyListMorph > do: > self drawOn: Display getCanvas > > and watch how slow its rendering! > > With Object class selected: > [self drawOn: Display getCanvas ] timeToRun 7887 > > > On 21/09/2007, Damien Cassou <[hidden email]> wrote: >> 2007/9/21, Cédrick Béler <[hidden email]>: >>> Something like that... Browsing Objects is slow since icons are >>> displayed in the method list...Basically, I think there is a full >>> lookup >>> at all methods and not only those that are visible (is it easily >>> changeable ?). This slow display basically occurs in Object which is >>> easy to understand. I added some otherkind of Icons (call super and >>> other stuff) and this was terribly slow.... Either we could >>> desactivate >>> OBIcon for Object (not optimal but easy) or adopt another Icon >>> mapping >>> strategy ? >> >> >> Icons are cool but they are really like DynamicProtocols which proved >> to be slow. Having both of them is really too slow. I think we need >> both, but everything has to be optimized. >> >> -- >> Damien Cassou >> >> >> >> > > > -- > Best regards, > Igor Stasenko AKA sig. > |
In reply to this post by Damien Cassou-3
On 23/09/2007, Damien Cassou <[hidden email]> wrote:
> What can we do? Do you have some time to help improving this situation? > I think i will. Its interesting, why it appears incrementally on screen, instead of rendering everything offscreen and the appear with single screen update. These deferUpdates: / forceToScreen: messages is quite confusing.. > 2007/9/21, Igor Stasenko <[hidden email]>: > > I just vent to OB window and came deep to inspect the instance of > > OBLazyListMorph > > do: > > self drawOn: Display getCanvas > > > > and watch how slow its rendering! > > > > With Object class selected: > > [self drawOn: Display getCanvas ] timeToRun 7887 > > > > > > On 21/09/2007, Damien Cassou <[hidden email]> wrote: > > > 2007/9/21, Cédrick Béler <[hidden email]>: > > > > Something like that... Browsing Objects is slow since icons are > > > > displayed in the method list...Basically, I think there is a full lookup > > > > at all methods and not only those that are visible (is it easily > > > > changeable ?). This slow display basically occurs in Object which is > > > > easy to understand. I added some otherkind of Icons (call super and > > > > other stuff) and this was terribly slow.... Either we could desactivate > > > > OBIcon for Object (not optimal but easy) or adopt another Icon mapping > > > > strategy ? > > > > > > > > > Icons are cool but they are really like DynamicProtocols which proved > > > to be slow. Having both of them is really too slow. I think we need > > > both, but everything has to be optimized. > > > > > > -- > > > Damien Cassou > > > > > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > > > > > > > > -- > Damien Cassou > > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by cbeler
>> Such behavior indicates that there is something wrong with List(or >> PluggableList) morph, which thinks that its not clipped and trying >> rendering all items, instead of those, which you can actually see. >> Of course, its only a suggestion. >> > Something like that... Browsing Objects is slow since icons are > displayed in the method list...Basically, I think there is a full lookup > at all methods and not only those that are visible (is it easily > changeable ?). Actually it does only lookup those methods that are visible. This works well. But the strange thing I noticed is that it always looks up all those visible methods again when I just move over a method name with the cursor... I couldn't yet find out why this happens and if it's needed. David |
Free forum by Nabble | Edit this page |