[antlr-interest] More, Status of C++ backend?

[Mark Wright]

> > Hello Ruslan and Jim,
> > 
> > Another idea is:  maybe it might be easier to find a way to
> > optionally plug in Andrei Alexandrescu's flex_string instead of
> > std::string. flex_string is used in the Boost Wave project,
> > presumably for the same reason.
> 
> But does flex_string require allocation by new()?
> I assume that YES.

Hello Ruslan,

flex_string uses policy based design, so you can choose
whether you want it to use new() or your own allocator:

http://www.ddj.com/cpp/184403784

> And again, profiler show main problems from this new/delete =>
> malloc()/free() allocations.

There are platforms such as Windows and Solaris where the
default malloc()/free() implementations have performance
issues with:

- multi-threading mutexes.  On Solaris you can use libmtmalloc instead.

- the underlying allocator.

Since you can choose to use your own allocator with flex_string,
I think there is a good chance that flex_string using
a per-thread memory pool (hence no mutex overhead) and a
custom allocator could outperform implementations
that do not have these features.
 
> Stack of profiler show deep for our SQL parser e.g. On 25-30 methods.
> Each method itself eat e..g. 0.9% of time.
>     0.8% is in fact LA() calls.
> 
> So there is no obvious bottleneck place. Its spread over all calls.
> 
> In SqlLite's Lemon parser deep of stack is only about 7-10 methods.
> And I am sure they do not do this overhead allocations.
> 
> 
> --------
> Aha, I see what you mean, Mark.
> 
> Probably flex_string uses POINTERs and do not copy inside?

You can choose the policies.

> Well, this may speed up 50% of potential ..
> 
> I will try to check this way. Should be relatively easy.
> 
> 
> ---------
> And one more thing.
> 
>     MEMORY POOL
> 
> I believe that C/C++ runtimes of ANTLR should be armed by this things
> always.

This is easy to plug into flex_string.

> And give to develop this way:
> 
>     pool -> all AST nodes and may be even our SQL nodes we allocate
> from it. then we trash the whole tree by single call of
> pool.free_all()
> 
> I know that few developers have use this way, and say this improve a
> lots speed. So why we all need invent a bike?

I think you will like Andrei's article.

Thanks, Mark
 
> -- 
> Best regards,
> 
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
> 
> Valentina - Joining Worlds of Information
> http://www.paradigmasoft.com


--