[antlr-interest] syntactic predicates and exceptions

[Terence Parr]

On Nov 15, 2005, at 4:24 PM, Pete Gonzalez wrote:
> First, exceptions are slooooow in C#.  I am working on a real-world  
> project that parses a text file containing relatively simple field/ 
> value pairs. We're using the lexer from Robin Debreuil's C# grammar  
> example, which I assume is reasonably well designed.  On my 2.4Ghz  
> Pentium PC, the input file (which is only 8671 lines / 228969  
> bytes) takes 840 ms to parse. This is pretty damn slow by yacc  
> standards, but certainly usable.  However, when running in the  
> debugger, I was shocked to find that the same parser takes 55.062  
> seconds, which is totally unacceptable, especially when you  
> consider that the application will eventually have to parse  
> thousands of files, not just a measly 8000 lines.  Why so slow?   
> Exceptions.

Hi.  First, are you parsing C# or are you parsing simple field/value  
pairs?  Second, yes exceptions are slooooow!  Best to avoid syntactic  
predicates if you can.  I've seen people use them in exceptions and  
get exponential behavior.

> If you are a Java person applying Java thinking to C#, you'll  
> probably say "well the C# compiler is broken -- those performance  
> issues are a Microsoft flaw, not an Antlr problem."  I disagree.   
> In my experience, C# libraries simply don't throw hundreds of  
> exceptions per second, and most exceptions correspond to real  
> errors that end up being displayed in the GUI.  Since the Antlr web  
> site very clearly advertises support for C#, I think this should  
> warrant at least a gesture at compliance with the conventions for  
> this platform.  In case there's any doubt, here's an unambiguous  
> excerpt from a Microsoft "Best Practices" document:
>
> http://tinyurl.com/aqzzh
> > Exceptions Are For Exceptional Circumstances
> >
> > Do not throw exceptions as a means of communicating between
> > components -- use events for that. Exceptions should not be
> > thrown in cases where completely expected results occur. For
> > example, a component that reads text files should not throw an
> > exception when it reaches the end of the file. This is a case
> > where an event would be appropriate. By limiting throwing
> > exceptions to exceptional cases, you will help developers to
> > debug their application rapidly by not having to wade through
> > numerous 'expected' exceptions.

Yes, in generated programs however I believe it's an "exception" to  
the rule. ;)  That said, I'm going to try to avoid exceptions in v3.

> This brings us to my second point:  trying to debug a application  
> with Antlr calls.  In C#, NORMALLY in I would just set my debugger  
> to break whenever an exception is thrown, and then hit F5 a few  
> times until I reach the bug.  With Antlr, this is no longer  
> possible.  Instead I have to turn off exception trapping, set a  
> breakpoint somewhere near the problem but after the parser has  
> finished, run to the breakpoint, then then re-enable exception  
> trapping to catch the "real" error.  If Antlr is being called in a  
> loop, this often requires hacking the code to add some kind of  
> counter or if/then test around the breakpoint.  This is what  
> Microsoft means when they say "wade through numerous expected  
> exceptions", and it is a real headache.

Agreed.  Debugging is not a problem until you say "run until you hit  
an exception".

> In conclusion:  With regards to Java, we've discussed three  
> possible choices (exceptions, no exceptions, or supporting both),  
> and there have been good arguments in favor of each choice.  But  
> for the C# version, I don't see how there can be any debate at all.

Thanks very much for the valuable info.  I'm going to try for no- 
exceptions to see what happens.  Note that v3 should make syn preds  
MUCH less needed.

Ter