[Pharo-project] [Fix] Issue890 Mantis6535 SortedCollection loose sortBlock
http://code.google.com/p/pharo/issues/list?updated=890 ready for inclusion Use SLICES described in my last comment Sorry I left some garbage in the PharoInbox, but it's quite unhandy to manage incremental dependency (when order of changes DOES matter). Wouldn't atomic loading be an easy solution for such problems? I usually don't complain, but here are my feelings: <rant> Monticello is quite a drag, and pharo feels globally unresponsive (even the core image). I still experiment some lost keystroke and menus are sometimes gooey. It's not rare I click on the wrong item. If 3GHz Intel core2 duo 64 bits really becomes a requirement, I will give Cuis a ride to get some fresh air ;) To me UI feel is mitigating all the good job made so far. </rant> Nicolas
On Jun 16, 2009, at 10:10 PM, Nicolas Cellier wrote:
http://code.google.com/p/pharo/issues/list?updated=890 ready for inclusion Use SLICES described in my last comment
Sorry I left some garbage in the PharoInbox, but it's quite unhandy to manage incremental dependency (when order of changes DOES matter).
I will clean it up. And yes this is not really satisfactory.
Wouldn't atomic loading be an easy solution for such problems?
in theory it would and I would love to. Now I need a week without students, emails, papers and I want to have a look at MC1.5 but so far I could not find the time.
I usually don't complain, but here are my feelings: <rant> Monticello is quite a drag,
I think that monticello is really cool compare to cs. Now with atomic loading and other speed up it should be really better
and pharo feels globally unresponsive (even the core image).
I'm planning to replace package info by some real packages but it takes times
I still experiment some lost keystroke and menus are sometimes gooey.
this is strange because on mac we do not have that behavior
It's not rare I click on the wrong item. If 3GHz Intel core2 duo 64 bits really becomes a requirement, I will give Cuis a ride to get some fresh air ;)
It should not. But really we are really paying attention to go faster on the UI level So I hope that the morphic cleaning + sensor will pay off.
To me UI feel is mitigating all the good job made so far.
we are doing our best. But we accept speed up proposal at the scrollbar level If somebody wants to integrate the speed up made on cuis for the UI then feel free. I think that once 1.0 is out of the door the first thing we should do as a community is to take time to rethink our tools. Stef
Hi Nicolas, On Jun 16, 2009, at 22:10 , Nicolas Cellier wrote: [...]
<rant> Monticello is quite a drag, and pharo feels globally unresponsive (even the core image).
Yep, responsiveness can be improved. The core feels quite fast for me (on a MacBook Pro), but still, for example opening a browser is not instantaneous. Also, if you type really fast, the characters start appearing late (I think Bill complained about that recently). OB is another story. For me, its at the border of being usable because of its slowness. [...]
To me UI feel is mitigating all the good job made so far.
So we should try to improve the GUI performance of the core. However, I'm not sure who can help... Cheers, Adrian
OB is another story. For me, its at the border of being usable because of its slowness.
Just for the record: OB included with the Seaside One-Click image is only marginally slower than the standard system browser. Opening and closing OB system browser on the class WACounter: 636.15 ms Opening and closing SystemBrowser on the class WACounter: 555.00 ms Lukas -=--=--=--=--=--=--=--=--=--=--=--=--=--=- " Omni Browser " [ browsers := (1 to: 20) collect: [ :each | OBSystemBrowser onClass: WACounter ]. browsers do: [ :each | each open. World doOneCycle ]. browsers do: [ :each | each close. World doOneCycle ] ] timeToRun / 20.0 " System Browser " [ browsers := (1 to: 20) collect: [ :each | Browser new setClass: WACounter selector: nil ]. browsers do: [ :each | Browser openBrowserView: (each openEditString: nil) label: 'System Browser'. World doOneCycle ]. browsers do: [ :each | each changed: #close. World doOneCycle ] ] timeToRun / 20.0 -=--=--=--=--=--=--=--=--=--=--=--=--=--=- -- Lukas Renggli http://www.lukas-renggli.ch
Thanks, I like benchmarks! I've run this in the recent Pharo-core and Pharo images (on the class String): Pharo core 10432 SystemBrowser: 686.6ms Pharo0.1-10342dev09.06.3 SystemBrowser: 940.8ms Pharo0.1-10342dev09.06.3 OBSystemBrowser: 1087.1ms Similar to Lukas' results is that the OBSystemBrowser is not that much slower than the normal SystemBrowser (slowdown of 15%). However, there is a larger difference between the SystemBrowser in Pharo and in Pharo- core (37%). Hence other features seem to contribute to the slowdown: freetype fonts, code highlighting, ...? Adrian On Jun 17, 2009, at 11:18 , Lukas Renggli wrote:
OB is another story. For me, its at the border of being usable because of its slowness.
Just for the record: OB included with the Seaside One-Click image is only marginally slower than the standard system browser.
Opening and closing OB system browser on the class WACounter: 636.15 ms Opening and closing SystemBrowser on the class WACounter: 555.00 ms
Lukas
-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
" Omni Browser " [ browsers := (1 to: 20) collect: [ :each | OBSystemBrowser onClass: WACounter ]. browsers do: [ :each | each open. World doOneCycle ]. browsers do: [ :each | each close. World doOneCycle ] ] timeToRun / 20.0
" System Browser " [ browsers := (1 to: 20) collect: [ :each | Browser new setClass: WACounter selector: nil ]. browsers do: [ :each | Browser openBrowserView: (each openEditString: nil) label: 'System Browser'. World doOneCycle ]. browsers do: [ :each | each changed: #close. World doOneCycle ] ] timeToRun / 20.0
-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
did you disable dynamic protocols? On Jun 17, 2009, at 12:17 PM, Adrian Lienhard wrote:
Thanks, I like benchmarks! I've run this in the recent Pharo-core and Pharo images (on the class String):
Pharo core 10432 SystemBrowser: 686.6ms Pharo0.1-10342dev09.06.3 SystemBrowser: 940.8ms Pharo0.1-10342dev09.06.3 OBSystemBrowser: 1087.1ms
Similar to Lukas' results is that the OBSystemBrowser is not that much slower than the normal SystemBrowser (slowdown of 15%). However, there is a larger difference between the SystemBrowser in Pharo and in Pharo- core (37%). Hence other features seem to contribute to the slowdown: freetype fonts, code highlighting, ...?
Adrian
On Jun 17, 2009, at 11:18 , Lukas Renggli wrote:
OB is another story. For me, its at the border of being usable because of its slowness.
Just for the record: OB included with the Seaside One-Click image is only marginally slower than the standard system browser.
Opening and closing OB system browser on the class WACounter: 636.15 ms Opening and closing SystemBrowser on the class WACounter: 555.00 ms
Lukas
-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
" Omni Browser " [ browsers := (1 to: 20) collect: [ :each | OBSystemBrowser onClass: WACounter ]. browsers do: [ :each | each open. World doOneCycle ]. browsers do: [ :each | each close. World doOneCycle ] ] timeToRun / 20.0
" System Browser " [ browsers := (1 to: 20) collect: [ :each | Browser new setClass: WACounter selector: nil ]. browsers do: [ :each | Browser openBrowserView: (each openEditString: nil) label: 'System Browser'. World doOneCycle ]. browsers do: [ :each | each changed: #close. World doOneCycle ] ] timeToRun / 20.0
-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jun 17, 2009 at 1:36 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
did you disable dynamic protocols?
if dynamic protocols were the problem, they were only responsible of the 15% difference between the SystemBrowser and OB-one. The huge difference is between the Core and Pharo which means dynamic protocols are not responsible. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
one of the problem is that package are slow since they rely on class category. Stef On Jun 17, 2009, at 11:18 AM, Lukas Renggli wrote:
OB is another story. For me, its at the border of being usable because of its slowness.
Just for the record: OB included with the Seaside One-Click image is only marginally slower than the standard system browser.
Opening and closing OB system browser on the class WACounter: 636.15 ms Opening and closing SystemBrowser on the class WACounter: 555.00 ms
Lukas
-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
" Omni Browser " [ browsers := (1 to: 20) collect: [ :each | OBSystemBrowser onClass: WACounter ]. browsers do: [ :each | each open. World doOneCycle ]. browsers do: [ :each | each close. World doOneCycle ] ] timeToRun / 20.0
" System Browser " [ browsers := (1 to: 20) collect: [ :each | Browser new setClass: WACounter selector: nil ]. browsers do: [ :each | Browser openBrowserView: (each openEditString: nil) label: 'System Browser'. World doOneCycle ]. browsers do: [ :each | each changed: #close. World doOneCycle ] ] timeToRun / 20.0
-=--=--=--=--=--=--=--=--=--=--=--=--=--=-
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17.06.2009, at 04:39, Adrian Lienhard wrote:
Hi Nicolas,
On Jun 16, 2009, at 22:10 , Nicolas Cellier wrote:
[...]
<rant> Monticello is quite a drag, and pharo feels globally unresponsive (even the core image).
Yep, responsiveness can be improved. The core feels quite fast for me (on a MacBook Pro), but still, for example opening a browser is not instantaneous. Also, if you type really fast, the characters start appearing late (I think Bill complained about that recently).
OB is another story. For me, its at the border of being usable because of its slowness.
I wonder if OB would not be much faster if the auto-category feature would be turned off? Marcus
On Wed, Jun 17, 2009 at 2:32 PM, Marcus Denker<denker@acm.org> wrote:
I wonder if OB would not be much faster if the auto-category feature would be turned off?
are you talking about the dynamic protocols (long methods, override...)? They are much faster than before. You can disable them to see if they are a source of slowdowns by going to the preference browser, 'dynamic protocols' category. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
On 17.06.2009, at 09:34, Damien Cassou wrote:
On Wed, Jun 17, 2009 at 2:32 PM, Marcus Denker<denker@acm.org> wrote:
I wonder if OB would not be much faster if the auto-category feature would be turned off?
are you talking about the dynamic protocols (long methods, override...)? They are much faster than before. You can disable them to see if they are a source of slowdowns by going to the preference browser, 'dynamic protocols' category.
Helps a little... but it feels to me that displaying a method, the slowest part is the Annotationpane. Maybe we can turn that off? It's off in the core image, too. Marcus
On Wed, Jun 17, 2009 at 5:44 PM, Marcus Denker<denker@acm.org> wrote:
Helps a little... but it feels to me that displaying a method, the slowest part is the Annotationpane. Maybe we can turn that off? It's off in the core image, too.
I have tried disabling it but haven't felt any difference. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
Helps a little... but it feels to me that displaying a method, the slowest part is the Annotationpane. Maybe we can turn that off? It's off in the core image, too.
I have tried disabling it but haven't felt any difference.
Please check out the Seaside One-Click image. It is pretty fast, especially when using the standard Squeak look. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (6)
-
Adrian Lienhard -
Damien Cassou -
Lukas Renggli -
Marcus Denker -
Nicolas Cellier -
Stéphane Ducasse