> There are of course other reasons like complexity of language, size of compilation units etc… but optimization tends to be the biggest hit in my experience.

I guess you don’t have much experience with Swift. LLVM code generation may be slower than alternatives, but that’s more or less by a constant factor.

Swift’s type inference, on the other hand, can lead to a combinatorial explosion.

For example, https://www.hackingwithswift.com/articles/11/how-to-make-swi... claims that

  let sum = [1, 2, 3].map {
    String($0)
  }.flatMap {
    Int($0)
  }.reduce(0, +)

takes over 11 seconds to compile, while

compare this code:

  let sum = [1, 2, 3].map { (num: Int) -> String in
    String(num)
  }.flatMap { (str: String) -> Int? in
    Int(str)
  }.reduce(0, +)

takes about 75ms, and

  let numbers = [1, 2, 3]
  let stringNumbers = numbers.map {
    String($0)
  }
  let intNumbers = stringNumbers.flatMap {
    Int($0)
  }
  let sum = intNumbers.reduce(0, +)

compiles in 71ms.

Of course, all of these use LLVM, and likely even generate highly similar intermediate code.

Also, you’ll see these slowdowns even in debug builds that don’t ask LLVM to optimize code much.

Pretty rude to start your comment with the assumption that I’m not experienced with Swift. The rest of your comment would be more useful without the unnecessary condescension.

But nothing you said contradicts what I said either. Yes it’s easy to get into slow paths with Swift, but it’s also easy not to. Granted it takes a lot of up front knowledge to do so.

But even if you just stick to the LLVM portion, llvms debug mode is slower than cranelift and other toolchains debug modes. Debug doesn’t mean “no optimizations” whatsoever, nor does it mean efficient paths through the toolchain either.