((To me, that's the main advantage of generated parsers. Leaving efficiency etc. aside (which doesn't seem to play a major role, anyway),
Are there going to be performance penalties? Currently, GPC is many times slower than CW (probably a factor of 10 to 50 times slower, I haven't measured it), so it certainly would be undesirable to slow it down!
Did anyone suggest to slow it down?
"leaving efficiency aside" suggests it may be slow (at least to me).
That said, I imagine not much work has been done in to finding where the bottle necks are - has anyone done much in the way of profiling?
Have you? Otherwise, starting such a discussion is somewhere between pointless and FUD ...
It was just a question - has anyone done much in the way of profiling? If the answer is no, then perhaps one day I'll look at doing it. If the answer is yes, then there is presumably some available data - that's why I asked. If no one has ever profiled it, then it's quite possible that a quick profile could double the speed (at least that is my experience with un-profiled code, 2-10 times is not uncommon).
FTR, (a) IME most time is spent in code generation, even without optimizing,
I suspect this is correct because the Mac OS combined API file parses very quickly (in fact several times faster than CodeWarrior!). And that does not generate any code, just the .gpi file (except the init routine of course).
(b) AFAIK GLR parsers behave the same as LALR(1) in the cases the latter can handle, so the difference is only in the other cases between not being able to parse it at all and parsing it with perhaps a little more effort, and I don't see how RD parsers would do with essentially less effort.
Fair enough. Peter.