[antlr-interest] Yet another idea for a completlygenericTreeParser

[Martin Probst]

Hi,

just a small addition:

> As I have pointed out several times, "tons of extra nodes" is not what 
> the analysis shows.

That is true for the case when you maintain a list of unused wrapper 
nodes and reuse them. While that is definetly possible it create some 
effort to implement such a thing. Also, the statement from Sun is that 
it's nearly always a bad thing to do something like that (and I think 
they have good arguments for that).

So space performance wise you approach is only on a close par if you put 
some questionable extra burden on the ANTLR user.

But maybe the question we state is simply wrong. What is the use case 
for this? Where does an ANTLR user need to reuse trees generated by 
something he doesn't have access to?

Scott repeats his Eclipse IDE example, and in that case the overhead 
introduced by the current system might be 30000 nodes/hour, without node 
reuse. So what? I can't see any problem with GCing 30000 nodes/hour on a 
computer that's able to run Eclipse. I would be really surprised if that 
created an noticeable performance ditch.

With compilers & translators, I don't see the problem too. I would guess 
that only very few compilers actually consume "foreign" trees, and if 
they do, the performance overhead of some GCing compared to the overall 
cost is again neglectible.

The only application where you really have to pay that much attention to 
performance are probably high-load server applications. And in that 
case, most of the time you parse relatively short queries in a query 
language you implement yourself, so the tree is small and you probably 
have control over the type of the nodes anyways.

So basically my question is: who cares? If this is just about reducing 
GC cost in some IDE application by 30000 objects/hour (all of which are 
probably caught in generation 0) I really don't see the point of 
creating something complex, possibly hard to maintain, and of 
practically no use to most of the ANTLR users. Or even enforcing it on 
them(!), possibly resulting in a (very slight) performance reduction and 
again, maintenance overhead.

Regarding the casts in the parser, you can probably get rid of them in a 
lot easier way (--> generics).

Regards,
Martin