well so far for me at least pharo 5 works ok perfomance wise on my quad core imac and my dual core macbook air. The only serious slow down I have is when loading images but I suspect this code is forked from Squeak anyway.
System Browser was indeed a big issue with large classes but after FastTable it works fine. Overall I am very happy with Pharo. But I also avoid heavy computation with pharo. I am in favor of optimization coming later on development cycle. Like all things we need to grow a community of interested pharo developers that will us Pi not just as a toy but a useful device , the more we have the more likely is that someone will step in front of others to fix some of those issues. Personally I have a Pi which I bought mostly to support the project , I never found a reason to use it. I am actually on the opposite side of hi-tech graphics which also Pharo does not support at all. So I step in and bring that support to Pharo because I need it and because I love Pharo. Problems dont magically solve themselves, we need more contributors. On Fri, Mar 25, 2016 at 2:33 PM Esteban Lorenzano <[email protected]> wrote: > Hi, > > On 25 Mar 2016, at 12:52, Tudor Girba <[email protected]> wrote: > > 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. > > 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? > > > actually there is a tree implementation based on fast table, but I’m not > sure is production ready (Cyril can say something about). > But anyway since I never understood why we have a tree there (since we > will “open” attribute in next panel), I do agree, strongly :) > > > 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? > > > not sure, I open and it takes some seconds to actually show anything. I > thought it was caused because of the catalog refresh to populate projects, > but I’m not sure. > In any case, load catalog projects in spotter is cool, but we need to find > a better implementation. One that does not freezes spotter until it refresh > (remember, Pharo is also used in places with crapy connection or not > connection at all). > > > 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. > > > yes! > > if you want to suffer, do this experiment: > 1. open a Pharo2 and open debugger on anything > 2. then Pharo3, 4 and 5… feel the incremental slowdown > 3. cry :’( > > Esteban > > > 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 <http://nabble.com>. > > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > >
