On Thu, 5 Feb 2015, Marcus Denker wrote:
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.
Rebuilding the whole AST after every keystroke is possible, but keeping
it real-time is a bit challenging.
I would love to see an editor, which works on the AST directly - aka it
maps the source code to AST nodes, and just updates the smallest possible
subtree at each keystroke. Implementing such editor has it's challenges
ofc, like typing a single character can invalidate the whole code, but
the editor should keep the AST somehow in that case too.
Another way to see it: How would the original Smalltalk be designed if they
would have had 4GB RAM in 1978?
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…
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.
I think this is a different thing. Improvements are always welcome, as
long as they don't step on your toes.
About Slots: I don't see their advantages yet (other than bitfields, but
those are so rare in Smalltalk that I implement them causes no trouble.
And they are just an optimization over using multiple fields.).
Levente
Marcus
