[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