4 ms·

I'm not familiar enough to comment on what different feature set and different type of work each compiler does to compare the speed, but WOW, that's an INSANE q

I'm not familiar enough to comment on what different feature set and different type of work each compiler does to compare the speed, but WOW, that's an INSANE quick build speed. Was it always an explicit goal of theirs compilation speed? Is there any documentation of specific things they did to achieve that build speed?

mamcx 10y ago
Is a goal of pascal (Being famous for start as a 1-pass compiler). Delphi get it from that.
- topspin 10y ago
  It is also a goal of Go. Glacial C++ builds at Google was a prime motivator in the creation and design of Go.
mike_hearn 10y ago
I used to use Delphi a lot, in the 1990's. It's a few things. Compiler designed for compilation speed above all else. Delphi did not attempt to ever compete with other languages/toolchains on raw runtime performance of the generated code .... I don't recall ever seeing Borland/Inprise boast that a new version generated more optimal code. This is because the code the compiler produced was fast enough for Delphi's target market (desktop business apps) and it was still a lot faster than Visual Basic, and a lot more compact than Java, which were its primary competitors. Delphi sold new versions to developers by giving them new productivity tools: for desktop apps that spend all their time idling, raw code performance was rarely an issue. Single pass compiler. Structuring Delphi apps could be a nightmare. You could not have circular unit dependencies and breaking such dependencies could often be irritating as hell. Functions had to be declared in the right order. No preprocessor or include based model. "Units" defined their header and implementation in the same file, so the compiler could rapidly load a binary representation of what a unit exported whilst it was compiling. No generics. Thus, no explosion of code to generate at runtime, like with C++. Grammar that was very easy to parse. Compiler codebase that at its core was designed for very old computers, so is/was very tightly written. Probably more. That's just what I recall.
- chamakits 10y ago
  Sweet. Thanks for the info. That provides a lot more context. I never wrote Delphi myself, but I always appreciated it, because it was used to develop the first IDE I used fory first programming class. Bloodshed's Dev C++. Quite an impressive IDE, so I imagine Delphi was (still is? No idea) a great platform for desktop app development.
  - pjmlp 10y ago
    It is, but since Borland lost their vision how to sell software and the tools division changed hands a few times, they lost most of the customers. Nowadays most of them are enterprise customers with big maintenance contracts. Also for shops focusing on Windows only customers, Delphi cannot compete with .NET.
pjmlp 10y ago
That compilation speed tends to be common on the Wirth family of languages, since Algol days. Hence why many of us, Wirth fans, enjoy but aren't that much impressed by Go compilation speed novelty. Still it is good that they do pursue this goal, for newer generations not to assume C and C++ compilation speeds are normal and to be expected. Also C++ compilation can improve when moving away from its #include model. When VC++ "15" gets release we will get an improved linker with DB support and experimental module support.

mamcx 10y ago

Is a goal of pascal (Being famous for start as a 1-pass compiler). Delphi get it from that.

topspin 10y ago
It is also a goal of Go. Glacial C++ builds at Google was a prime motivator in the creation and design of Go.

mike_hearn 10y ago

I used to use Delphi a lot, in the 1990's. It's a few things. Compiler designed for compilation speed above all else. Delphi did not attempt to ever compete with other languages/toolchains on raw runtime performance of the generated code .... I don't recall ever seeing Borland/Inprise boast that a new version generated more optimal code. This is because the code the compiler produced was fast enough for Delphi's target market (desktop business apps) and it was still a lot faster than Visual Basic, and a lot more compact than Java, which were its primary competitors. Delphi sold new versions to developers by giving them new productivity tools: for desktop apps that spend all their time idling, raw code performance was rarely an issue. Single pass compiler. Structuring Delphi apps could be a nightmare. You could not have circular unit dependencies and breaking such dependencies could often be irritating as hell. Functions had to be declared in the right order. No preprocessor or include based model. "Units" defined their header and implementation in the same file, so the compiler could rapidly load a binary representation of what a unit exported whilst it was compiling. No generics. Thus, no explosion of code to generate at runtime, like with C++. Grammar that was very easy to parse. Compiler codebase that at its core was designed for very old computers, so is/was very tightly written. Probably more. That's just what I recall.

chamakits 10y ago
Sweet. Thanks for the info. That provides a lot more context. I never wrote Delphi myself, but I always appreciated it, because it was used to develop the first IDE I used fory first programming class. Bloodshed's Dev C++. Quite an impressive IDE, so I imagine Delphi was (still is? No idea) a great platform for desktop app development.
- pjmlp 10y ago
  It is, but since Borland lost their vision how to sell software and the tools division changed hands a few times, they lost most of the customers. Nowadays most of them are enterprise customers with big maintenance contracts. Also for shops focusing on Windows only customers, Delphi cannot compete with .NET.

pjmlp 10y ago

That compilation speed tends to be common on the Wirth family of languages, since Algol days. Hence why many of us, Wirth fans, enjoy but aren't that much impressed by Go compilation speed novelty. Still it is good that they do pursue this goal, for newer generations not to assume C and C++ compilation speeds are normal and to be expected. Also C++ compilation can improve when moving away from its #include model. When VC++ "15" gets release we will get an improved linker with DB support and experimental module support.