2016-03-25 12:52 GMT+01:00 Tudor Girba <[email protected]>: > Hi, > > > On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <[email protected]> > wrote: > > > >> > >> On 25 Mar 2016, at 07:43, Clément Bera <[email protected]> wrote: > >> > >> Yeah this is very well-known. Note that here we are talking about the > pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the > pie A to open Nautilus on the stack vm while the Squeak UI was usable. > >> > >> The Pharo UI has been focusing on IDE features at the cost of > performance, such as auto-completion, better RB integration, Nautilus, new > debugging tools... None of the current tools (Nautilus, GTInspector, > GTPlayground, ...) are fast enough for slower devices, some of them are > barely fast enough for a laptop (for example at some point there was no > auto-refresh on GTInspector because of performance). It's not clear if it's > due to the new tools themselves as Morphic is drastically slower too on > Pharo. > >> > >> The Squeak UI has been focusing on performance and stability. It is > very convenient for slow devices but also for slow VM like for example the > debug VM. > >> > >> The official answer to this problem is that Block/Brick will be faster > so it will solve all this problems. We will see. > > > > yes, this is the “semi-official” answer and that’s an error. Yes ideally > it will solve some problems (the ones related to Morphic), but current lack > of performance on Pharo tools is not because of Morphic but because of some > non optimised choices. > > For example, months ago I got pissed because our current list > implementation was not fast enough for our tools and that’s why I made > FastTable: because it was evident we needed a better design for it. It > speeded the startup of Nautilus by an order of magnitude. This is a widget > developed with Morphic, but with a not-naive approach, so is fast. > > As lists, some others widgets (notably tree) could be optimised… > > But this will not be the solution of the problem either: we need to > spend time on optimisation. Nautilus is not a good tool (we all know it has > design problems all around) but with the time had improve and not using it > is almost enjoyable… but for example, the new debugger (which I’m not > criticising as a tool, I like it a lot) makes me hurt… is slower than > eclipse debugger and that’s a lot to say. > > That is a good one :). There is an open issue with the blinking problem > when you accept code which makes it appear slower than it actually is, but > we are stuck with it and we could benefit from help. >
"appear slower than it actually is" Really? Aliaksei comment was: "Each code accept triggers a lot of glamour inner stuff and in the end refreshes the almost whole debugger interface. (Panes, Tabulator, LazyTable and so on)" So, is it slow, or does it just look slow? > > > Also new inspector: is good, but can’t we optimise it? maybe we need to > make some concession, but is the moment of doing it. > > The optimization we should do now is to replace the appearances of > MorphTreeMorph with FastTable. This would imply that the Raw presentation > would not longer have a tree (because it is not supported in FastTable). I > would be very happy if we could do that. Do we agree on this? > > > Recently I’m noticing a slowdown in Spotter: I believe is because one of > his categories is refreshing to the network but I’m not sure: this slowdown > is not production acceptable, for me is a Show Stopper because it kills the > usability of the tool (of a tool who is great, but it HAS to be fast, > otherwise is useless). > > Could you be more specific about the Spotter problem that you see? > > Also, in the last couple of days Alex Syrel improved the speed of Spotter > significantly. It is not yet integrated. It would be useful to get feedback > on this because maybe we missed something. > > > > Mea culpa: more than once I have not protested even knowing than > solution X was “10% slower than the older one, but that’s ok, we can live > with it”… guess what? once you accumulate enough of those 10% penalties, > you have a barely usable system. > > > > We need to concentrate efforts on performance. There will not be magical > solution: if we do not spend time on enhance tools for performance, they > will be not good enough. > > > > Can I ask you guys to spend some time optimising tools, before we > release Pharo 5? Remember, “First impressions counts”! (we even have a > category for it in FogBugz). > > It would indeed be useful to get more eyes spent on this. > > Cheers, > Doru > > > > > Esteban > > > > > > > >> > >> > >> 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <[email protected]>: > >> > >> > [Squeak 5 is] so *fast* (I have it running next to > >> > Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping > >> > along at Windows desktop speeds on the Pi (Model B). > >> > >> > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> View this message in context: > http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html > >> Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > >
