Thread history
 Time |
User | Activity | Comment |
|---|---|---|---|
| No results | |||
The problem is in my opinion not that CLang is that bad. On the contrary: I think the problem is that it tries to optimize the output of bison when other compilers don't. At least in the past a sure-fire way to get your code NOT (or only superficially) optimized was to add goto to it. Most optimization algorithms assume that there is only one way to enter a code block and if you use goto you break that promise and most compilers say "OK. I will not even try to optimize this garbage". The bison/flex code contains quite a number of AND the source files generated are quite large. CLang seems to try to optimize them with O3. The memory usage seems to vary for different versions of CLang. Ah. And by the way: the error messages of CLange are MUCH more readable than the stuff g++ prints
Nice! I already knew that CLang provides a better warning/error messages, as well as helping find some issues without the need of some other lint software, but I had no idea that it tried to optimize the output from bison et al!
OK, I'll update the note with this in mind.
The problem is that optimizing the parser for swak is futile: the time spent doing the actual parsing is small compard to the actual "OF-work": calculations on the fields. That's why I added the special optimiziation switch for the parsers.
PS: and this "tries to optimize goto-stained code" is only a theory (I haven't looked at the source. But its behaviour - certain CLang versions freeze a 8 Gig machine when compiling FieldParser with O3 - make me pretty sure that this is the case)
