Diego
I found that in the 6272 image (may be before) the UI is reacting more slowly than with previous 3.8 unstable images. Does anybody else see that? Diego have you noticed something too? I'm on mac.
Stef
Am 30.09.2004 um 21:03 schrieb stéphane ducasse:
Diego
I found that in the 6272 image (may be before) the UI is reacting more slowly than with previous 3.8 unstable images. Does anybody else see that? Diego have you noticed something too? I'm on mac.
We should enable the fastDragWindowForMorphic again: Moving a window is extremely slow. It takes a huge amount of time to calculate the shadow, I guess.
Another thing that slows things down are all the bells and whistles enabled while browsing, especially the annotationpanes.
And we need to disable prettyPrint: This is annoying with the current system.
Marcus
tttttttttrrrrrrrrrrrrrrrrrrruuuuuuuuuuu.......... . . ... . . . e On 1 oct. 04, at 08:02, Marcus Denker wrote:
Am 30.09.2004 um 21:03 schrieb stéphane ducasse:
Diego
I found that in the 6272 image (may be before) the UI is reacting more slowly than with previous 3.8 unstable images. Does anybody else see that? Diego have you noticed something too? I'm on mac.
We should enable the fastDragWindowForMorphic again: Moving a window is extremely slow. It takes a huge amount of time to calculate the shadow, I guess.
Another thing that slows things down are all the bells and whistles enabled while browsing, especially the annotationpanes.
And we need to disable prettyPrint: This is annoying with the current system.
Marcus
Stef,
I didn't notice of it, but in absent of profiling I *guess* the slowness comes from the horizontal-scrollbars. The lists embedded into browsers, debugger, etc are much bigger than before.
Cheers,
-- Diego
PS: Can you profile it? World Menu >> debug.. >> start MessageTally
Diego
I found that in the 6272 image (may be before) the UI is reacting more slowly than with previous 3.8 unstable images. Does anybody else see that? Diego have you noticed something too? I'm on mac.
Stef
So, why don't you write a test for it?
:-)
testForSlugishness self assert: [Browser open "and other stuff you do"] timeToRun < "some reasonable delay for that"
True, this will fail for slow machines, but that reasonable.
Daniel
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
Diego
I found that in the 6272 image (may be before) the UI is reacting more slowly than with previous 3.8 unstable images. Does anybody else see that? Diego have you noticed something too? I'm on mac.
Stef
On Oct 2, 2004, at 2:59 AM, danielv@tx.technion.ac.il wrote:
So, why don't you write a test for it?
:-)
testForSlugishness self assert: [Browser open "and other stuff you do"] timeToRun < "some reasonable delay for that"
True, this will fail for slow machines, but that reasonable.
Actually, better yet you could have a quick tinyBenchmarks test as part of the testForSlugishness to use as a sort of baseline for machine speed. Then, you could test that "Browser open" or whatever only takes a certain amount of time relative to your sends/sec speed, so it should be roughly equivalent on slow & fast machines.
- Doug
Daniel
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
Diego
I found that in the 6272 image (may be before) the UI is reacting more slowly than with previous 3.8 unstable images. Does anybody else see that? Diego have you noticed something too? I'm on mac.
Stef
Doug Way wrote:
On Oct 2, 2004, at 2:59 AM, danielv@tx.technion.ac.il wrote:
So, why don't you write a test for it?
:-)
testForSlugishness self assert: [Browser open "and other stuff you do"] timeToRun < "some reasonable delay for that"
True, this will fail for slow machines, but that reasonable.
Actually, better yet you could have a quick tinyBenchmarks test as part of the testForSlugishness to use as a sort of baseline for machine speed. Then, you could test that "Browser open" or whatever only takes a certain amount of time relative to your sends/sec speed, so it should be roughly equivalent on slow & fast machines.
There is a problem with timeToRun: it is not independent from other running Squeak or system processes. Better would be a measurement of executed bytecodes and message sends for just this test, which should be independent from interrupts. This is especially important for tests, which mustn't fail.
Any idea?
Greetings Stephan
- Doug
Daniel
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
Diego
I found that in the 6272 image (may be before) the UI is reacting more slowly than with previous 3.8 unstable images. Does anybody else see that? Diego have you noticed something too? I'm on mac.
Stef
I wrote:
Doug Way wrote: ...
Actually, better yet you could have a quick tinyBenchmarks test as part of the testForSlugishness to use as a sort of baseline for machine speed. Then, you could test that "Browser open" or whatever only takes a certain amount of time relative to your sends/sec speed, so it should be roughly equivalent on slow & fast machines.
There is a problem with timeToRun: it is not independent from other running Squeak or system processes. Better would be a measurement of executed bytecodes and message sends for just this test, which should be independent from interrupts. This is especially important for tests, which mustn't fail.
Any idea?
Interesting, too, could be a CPU running time for *each* Smalltalk process: but how to realize without compromising VM performance? Or wouldn't this be an issue?
Greetings Stephan
...
squeak-dev@lists.squeakfoundation.org
-
danielv＠tx.technion.ac.il -
Diego Gomez Deck -
Doug Way -
Marcus Denker -
Stephan Rudlof -
stéphane ducasse