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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Nicolas Cellier
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Lukas Renggli
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Lienhard
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Wed, Jun 17, 2009 at 1:36 PM, Stéphane
Ducasse<[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Lienhard
do we have an idea of the source of slow down?
> > Pharo core 10432 SystemBrowser: 686.6ms > Pharo0.1-10342dev09.06.3 SystemBrowser: 940.8ms _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Lienhard
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Wed, Jun 17, 2009 at 2:32 PM, Marcus Denker<[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On 17.06.2009, at 09:34, Damien Cassou wrote: > On Wed, Jun 17, 2009 at 2:32 PM, Marcus Denker<[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Wed, Jun 17, 2009 at 5:44 PM, Marcus Denker<[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |