> On 05 Feb 2015, at 10:46, Thierry Goubier <[email protected]> wrote: > > > > 2015-02-05 10:12 GMT+01:00 Marcus Denker <[email protected]>: > > > On 05 Feb 2015, at 10:04, Marcus Denker <[email protected]> wrote: > > > > > >> On 04 Feb 2015, at 22:04, Levente Uzonyi <[email protected]> wrote: > >> > >> A single parser is a nice goal, but performance is top priority for Shout, > >> because it should do it's job real-time. When it starts lagging behind, > >> then people just turn it off, because it doesn't help them. > >> Can those parsers (SHRBTextStyler and a Smalltalk parser written using > >> PetitParser) parse an average method in less than 20ms on an average > >> machine? > > > > I have not yet benchmarked it… PetitParser as it is is too slow, but we > > will soon have a faster version (factor 10). > > > > We should do some benchmarks. For using, it seems ok. With a fast machine + > > JIT, which does not say much of course. > > (there is a setting 'AST based coloring’ in Pharo3 and Pharo4, but it is > > turned off by default). > > > > One thing that is nice with the AST is that it can be used for other > > things, too. e.g. in Pharo we have a menu that is defined > > by the AST nodes and structural navigation in the editor. > > > > Another way to see it: How would the original Smalltalk be designed if they > would have had 4GB RAM in 1978? > > Badly for today's machines :) > > > What fascinates me still is that Smalltalk used the existing resources (even > building their own machines) to an > extreme, while today we are obsessed to find reasons why we can not do > anything that makes the system > slower or use more memory than yesterday. And that even with resources > growing every year… > > You're spoiled by your nice and expensive macbooks :) > > Honestly, on some of today's machines, you'd better avoid long methods or GT > tools stuff because they are slow. > > SmaCC code generation is slow. > > PluggableTreeMorph is slow. > > Nautilus is slow. > > Loading large configurations is slow. > > Roassal complex graphs are slow. > > Serge's modeling stuff is slow. > > PetitParser has performance problems. > > BitBlt is slow (and Cairo has bugs). > > > This is why we e.g. now have a meta object describing every instance variable > in Pharo. I am sure there are people > who will see these ~7000 objects as pure waste… while I would say that we > have already *now* the resources to be > even more radical. > > Being radical in the context of Pharo is offering to remove stuff or layers > :):) > > Thierry
It is obviously a compromise (or a continuum) between abstractions and performance. But there should remain a focus on efficiency (not just speed but also memory), it is hard to fix these things years later.
