[antlr-interest] FEATURE REQUEST: continued and memory/speedissues

[Ric Klaren]

On Sun, 2 Jan 2005 20:33:14 -0800 (PST), Akhilesh Mritunjai
<virtualaspirin at yahoo.com> wrote:
> Ric, I agree that it will be a maintenance headache.
> On the contrary, this is by and large only way to
> satisfy both, who need speed and who need flexibility.

That's true, yet I want to get rid of most of the preprocessor 'junk'
one of these days. So I'm  not that enthousiastic to start adding now.

> Personally, I don't understand why making things
> virtual will be so significant change... in Java every
> method is virtual by default and in my test case it is
> twice as fast as C++ and at same time consumes a third
> less memory.

Would be interesting to see that grammar. Most of my 'benchmarks'
(only looking at speed) show that C++ is faster, so I guess it could
be a grammar thing. Adding a few virtuals won't hurt that much is my
guess. Making the whole ASTFactory virtual might have more of a hit
depending on the amount of tree building being done. Guess I'll stick
to making the create's virtual and see whoever needs more. The speed
lovers can always make a vendor branch of the runtime to tweak to
their needs and compilers.

> > Combine that with the fact that I'm limited in time
> > I can spend on antlr makes things simple
> optimization
> > stuff goes last period.
> 
> Ric, thanks a ton for your time and efforts :-) You
> folks are doing one hell of a job!!

You're welcome :)

> I personally will be very happy to help in this
> regard. Can I send you the diffs ? If yes, then
> against which release ?

Yesterday I already went through the AST/Parser/CharScanner classes
and moved most small things into the header except for some methods
that aren't that time critical/called that often.

With -O2 optimization this did not make any significant change with
gcc 3.4.1 on win32/mingw :(. -O3 -fexpensive optimizations actually
made things worse speed wise. I should probably retest on linux box
but the linux box I'm using isn't that fast in compiling. Anyway the
changes should appease most people I hope ;)

> Oh, Happy new year to you all out there!

Also happy new year to all =)

Cheers,

Ric