2016-03-25 9:45 GMT+01:00 Esteban Lorenzano <[email protected]>: > > 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: >
But isn't the old list implementation (mostly) the same that is used in squeak (and feels faster there?) ? > 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. 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. > 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). > > 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). > > 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 <http://nabble.com>. >> >> > >
