BTW, no static parsers in KawaDD
Jonathan Revusky
> I know about making parsers static to make things faster.
Stuart, I saw that you wrote the above, like 3 months ago on the javacc
list.
As best I can determine from testing, making parsers static doesn't get
you very much. It might have, once upon a time, with early JVM's,
because invoking virtual methods was expensive.
I removed the STATIC=true as an option in KawaDD. Well, you can still
put in the option for now, but it's ignored. In fact, I ripped out all
the code for generating static parsers.
On the one hand, I had done some testing and it doesn't buy very much.
And then, on the other hand, having all these static variables around is
quite error-prone. It's quite easy to just have a hash that keeps
accumulating entries and never gets garbage-collected, say. And also,
the extra option has to be documented and explained, and the extra code
maintained. And, after all, AFAICS, there is nothing you can do with a
static parser that you cannot do with a non-static one. So I ripped it out.
KawaDD is still generating ReInit() methods, as if you're going to gain
very much by using the same parser and reiniting it instead of just
newing a new one. I think I'm going to rip that out too and just say
explicitly that parsers are disposable.
I think this is one advantage of starting a new project. I don't feel
quite so obliged to support all the older usage patterns. In any case,
the static parser issue shouldn't be painful. AFAICS, somebody who was
using a static parser, and wrote something like:
MyParser.reInit();
MyParser.setInputStream(input);
MyParser.rootProduction();
now has to write:
MyParser p = new MyParser(input);
p.rootProduction();
Out of curiosity, does anybody care about the static parsers getting
axed? Not that I am really asking for approval, since it's already been
done basically. :-)
JR
>
> I also believe that reducing lookahead and checking speeds up the parser.
>
> cheers
> stuart
>
>
> On Feb 10, 2008 7:02 PM, Laughing Man <xuinch...@hotmail.com> wrote:
>> Very little. It mentions that some of the options when turned on or off can result in parsers that run faster. I could even mention them all if Tom doesn't mind.
>> _________________________________________________________________
>> Express yourself instantly with MSN Messenger! Download today it's FREE!
>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-un...@javacc.dev.java.net
>> For additional commands, e-mail: users...@javacc.dev.java.net
>>
>>
Stuart A. Yeates
I've not used static parsers for months, simply because they're not
thread safe. Thread safety is indispensable for any kind of library
(since you don't know in advance how you're going to be called).
cheers
stuart
Jonathan Revusky
<LOL> Yes! Of course that's the first order reason not to have static
parsers. They're not thread-safe. I knew something was slipping my
mind. That was my main reason and the fact that it is easy to
introduce memory leaks was secondary. If you could really get
something to run twice as fast this way, it would be one thing, but it
might only be 5% or 10% or something like that. It would depend on the
exact case, I'm sure, but it's something like that. Or even less.
There are other weird options, like KEEP_LINE_COL which, at least has
the correct default (true). But for the savings in memory use
(trivial) who wants to throw away location information that could be
crucial when you troubleshoot the system that this parser is part of?
Like the static parser option, it's such a bad tradeoff that the
option hardly has any value AFAICS. I may remove that.
Cheers,
JR
>
> cheers
> stuart