Jonas Maebe wrote:
On 29 Jul 2010, at 11:05, Adriaan van Os wrote:
Jonas Maebe wrote:
If you put everything in a single compilation unit, then the compiler can optimize more, but if the goal is speeding up compilation then it will probably be counterproductive (possibly unless you only care about compilation speed for -O0 and not at all when using -O1 or higher).
It depends where the compiler is spending its time, generating code or processing declarations, reading unit symbols, etcetera. For GPC on Mac OS X, the bottleneck is absolutely the latter.
I don't think the current GPC unit loading architecture is comparable to how a C++ backend would work. And as I said, it is very much depends on the size of the compilation unit: larger compilation units generally take more or less linearly more time to parse, but the optimization time generally rises much more steeply (especially with newer compilers that perform more inter-procedural analyses).
I think so. Also, putting everything in one source file means that everything has to be recompiled with every change anywhere.
What's taking so long currently, Adriaan, is probably the GPI imports. That's independent of the target, i.e. a Pascal to C++ converter would have to do it just the same, so its complexity is independent of how the output is structured. As I said, this is a separate issue which would be easier to tackle if the compiler was written in a high-level language (such as C++ or Pascal with templates). It's easier to find and experiment with efficient data structures (e.g., hash tables, trees) when they're readily available than when you have to manually implement them each and every time like in C (for the current GPC) and also in Pascal so far.
BTW, is it the actual Mac OS X interfaces that are so huge, or your wrappers? I remember you had a long list of string functions for string types of various kinds and lengths. Using templates, they'd shrink drastically.
Frank