[antlr-interest] Re: BENCHMARK. ANTLR. Bad results.

[micheal_jor]

--- In antlr-interest at yahoogroups.com, Ruslan Zasukhin <sunshine at p...>
wrote:

> > More importantly, how can you convince other people to accept your
> > speculation?.
> 
> Alex Sedow already have give you exact numbers:
>     3-4 times speed up thanks to special string + allocator.

OK, I got a 5-7x speedup just by buffering the whole input (tested
with C# not C++). In your tests, were you reading from a file or
memory buffer?

> Do not worry. We will make profiling also and will try fix some
things self.
> Of course we will inform this list about results.

That would be very useful.

> > I can't but, I can at least ask that you take of one the simple
> > examples, generate the code then, modify a copy of the generated code
> > manually to implement the features you feel strongly about.
> > 
> > We can then test both versions. The results can then properly inform
> > the decisions that are made for v3 code generation.
> 
> Problem is that I do not have a lots of wish to study internals of
ANTLR and
> its algorithms. This is separate big task...

You won't be studying ANTLR internals. You would be studying the ANTLR
generated code for a small sample - which you already do for your much
larger project - and augmenting it with changes that you believe would
make it run faster.

> Exists major developers of ANTLR. I give an advice.
> It is business of these developers listen or not.
> It is business of these developers TRY and PROVE that std::string is
best of
> the best by speed.

True but, ANTLR is an open source project whose developers are drawn
from it's pool of users. If you - as a user - can contribute to make
it go faster, why not do it?. It's to your benefit [too] right?

> But if they will find that special class can give us AT LEAST 10% of
speed
> up, then I vote for new class. I hope my logic is clear ?   :-)

Crystal.

> Just I want underline. Many times was told:
>     parsing is so fast task comparing to MAJOR DBMS tasks.
> 
>     Now we have the first benches which show that our DBMS
>     can do work 10-15 times faster that parser itself.
> 
>     This means that _such_ parser become huge overhead for us.
>     this is not pleasant of course.

Too big an overhead in anyone's estimation I'd presume. But the change
to [F]Lex lexing should reduce that considerably. Add a large-ish
in-memory buffer and you should be much happier.

> I like ANTLR. We have spend 18 months with it.
> So I'd prefer get faster ANLTR that to be forced for new parser.

ANTLR is getting faster. It can get there even quicker with more
people/resources.

Micheal
ANTLR/C#





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/