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
