undefined | Better HN

0 pointsfastball1y ago0 comments

Are there any LLVM langs that have fast compile times? I think that just kinda comes with the territory of having that IR step + all the optimizations that happen at compile time to help runtime performance.

0 comments

easeout1y ago

That's a good point. I had in mind that there's some regret about the combination of type inference with type-based overloads, due to the search expense it adds to what ought to be straightforward parsing of long expressions.

fastballOP1y ago

Yeah, I think there are definitely parts of the language design / language features that are going to contribute, but when you need to parse to IR and then compile that to machine code, it seems any features you add that are nice for the developer are going to doubly hurt compile times. You see the same with ARC in swift (or the borrow checker in Rust).

saagarjha1y ago

Parsing IR and lowering it is not the reason why compiling Swift is slow.

1 more reply

Rohansi1y ago

AFAIK those language features are all handled in the frontend before outputting LLVM IR. LLVM optimization, code generation, linking, etc. should all be the same regardless of the source language.

easeout1y ago

I don't know about that example—when ARC was added to Objective-C back in the day, I don't remember clang feeling any slower as a result.

j / k navigate · click thread line to collapse

0 comments

easeout1y ago

fastballOP1y ago

saagarjha1y ago

Parsing IR and lowering it is not the reason why compiling Swift is slow.

1 more reply

Rohansi1y ago

AFAIK those language features are all handled in the frontend before outputting LLVM IR. LLVM optimization, code generation, linking, etc. should all be the same regardless of the source language.

easeout1y ago

I don't know about that example—when ARC was added to Objective-C back in the day, I don't remember clang feeling any slower as a result.

j / k navigate · click thread line to collapse