Hi Gerald,
> About the impact of C++11 memory management on performances, do you think an alternative to the shared_ptr could be considered?
I'm still not 100% settled yet. The current solution seems to work quite nicely and meanwhile the performance is close to the ANTLR3 C target (which is probably the fastest target you can get for ANTLR).
>
> Personally, I am expecting a parser to be simple and fast. One way to be fast could to allocate continuously from a large block of memory without recycling allocations at all, releasing the whole block once the parsing is done.
Well, what I don't want is an own memory manager. It's simply way too much for a single library. However I've been thinking about:
1) Implement own ref counting. I have done this in another application, so I know how to do it.
2) Use arenas (or zones) which get deallocated in one step when you free your parser (or the tree).
3) Use a parse context which serves as the manager of all the memory allocated during parsing and which frees everything one destruction (in the classic way with a delete call).
Keep in mind, however, that there are actually 2 areas where memory is used in the ANTLR runtime: the static data (DFA, ATN) which is shared among all instances of a specific parser/lexer class and can easily grow to half a GB (I have seen this with deeply nested expressions) and the transient data created during a parse run (mostly the parse tree, which you can switch off, btw.). I have lowered the memory load of the static data by that move from an array to a map for certain sparse containers (I mentioned that in an earlier mail) and it could be there is more to optimize. This static data can probably also be optimized to use no shared ptrs, which are currently required to keep objects alive that are held only by other substructures (e.g. ATN configs). Since this is static data, maybe we don't even need to care about destruction at all, as that stays alive anyway as long as the application is running.
Optimizing the parse tree is probably easier however, because it's mostly just the tree itself that holds the context instances and the only thing we have to make sure is that they are freed when the user no longer holds a reference to the tree. Here the idea of a parse context would fit quite well and this is what I'm currently roll around in my brain.
Mike
--
www.soft-gems.net