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

Ruslan Zasukhin sunshine at public.kherson.ua
Sat Nov 13 12:19:09 PST 2004


On 11/13/04 9:33 PM, "micheal_jor" <open.zone at virgin.net> wrote:

>> ---------------------------------------------------
>> We use C++ runtime of ANTLR.
>> Benches was in the release compile, with full optimization on.
>> 
>> We have not study yet deeply where are problems.
>> This is what we are going to do in the nearest time.
> 
> I was hoping you had run the code through a profiler to locate the
> bottleneck *before* posting the results. That would have given us much
> better performance info.
> 
>> Just I want to demonstrate that my expectation of bad performance of C++
>> ANTLR runtime have become reality.
>> 
>> * We will try urgently switch to Lex lexer.
> 
> Well, you have been involved in many threads on ANTLR/C++'s
> performance where the first advice is always to swich to a [F]Lex
> lexer and, there is a sample that demonstrates this.
> 
>> * but IMHO on of the main problems of ANTLR C++, is that it heavally uses
>> std::string class and a lots of *copying* of string when it parse tokens.
> 
> Perhaps, but without hard profiling data, how can you be certain?.

Oh Michael, I can.

Because last 10 years my main job is creation of super-fast piece of code.
I have made a lots of different profiles for a lots of algorithms,
with different compilers and different platforms.

So I hope I have enough experience to say "by eye measure"
that here or there things can be done better.

> 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.

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


>> * may be another problem is in exceptions, although I like mechanizm of
>> exceptions.
>> 
>> I think that for 3.0 Rick and community should produce own, special, very
>> optimized for ANTLR tasks antl::string class. This class should simply have 2
>> pointers on start/end of tokem. Pointer must point directly into original
>> parsed text. There is no need copy any byte of parsed text. Everything must
>> work on pointers. Tell me that I am wrong?! :-)
> 
> 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...

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.

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 ?   :-)


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.

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


-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------




 
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/
 





More information about the antlr-interest mailing list