3 ms·

When discussing compiler speed, Go specifically prioritizes compilation speed over optimization of the resulting code. Swift and Rust both suffer from slower c

• Someone 3y ago
  > 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-swift-compile-faster 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.
  • dagmx 3y ago
    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.