Peter N Lewis wrote:
((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).
For me it means that I do (did) not want to discuss it here (because it probably is irrelevant, and because probably nobody has any real facts -- for details about parsing algorithms and some efficiency considerations, you might want to read http://www.cs.vu.nl/pub/dick/PTAPG/).
My problem is that often people start discussions about efficiency without any real basis, replacing facts by opinions on what "ought to" be faster, and (almost) always without any actual [meaningful] measurements. (The only time I remember at all someone doing a systematical benchmark was Waldek some months ago about packed types -- though it was only for a special case which probably wasn't representative.) Maybe I take this a little personal because I've often had to deal with crappy code for the sake of efficiency (in GPC and in other projects) which almost always turned out to be not much faster (sometimes even slower) and/or irrelevant for overall efficiency, and causing a lot of extra work for those who wrote the code and those (usually me) who removed the code and replaced it by saner code.
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).
As I said, it's probably the code-generation which takes most of the time. This is a backend issue, so you might want to ask on the GCC list. (I suppose some have done profiling there, but I don't know who, where or what ...)
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).
Good to know, anyway. This means that my recent (2002-12) optimizations in the GPI area seem work as intended. (There were some actual bottlenecks (O(n^2) instead of O(n)) which I could actually measure ...)
Frank