Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Swift compiler is slow due to how types are inferred

danielchasehooper.com

Post reply on HN
Print view View original

81–90 of 229 posts

Re: The Swift compiler is slow due to how types are inferred

#81

Post by JackYoustra »

Decabytes wrote: post #13

I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode. A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains…

I would say the opposite, actually: at least on large pure swift projects, Xcode grinds to a halt. Many of its features come with unacceptable performance cliffs which are impossible to patch. I ran into a particular problem with the build documentation command recently: https://www.jackyoustra.com/blog/xcode-test-lag

Re: The Swift compiler is slow due to how types are inferred

#83

Post by JackYoustra »

vlovich123 wrote: post #48

The combinatorial explosion is intractable but since it only seems to come up in really obscure corner cases, I wonder if the typical inference scenarios can be solved by having the compiler cache the AST across invocations so that inference only needs to be performed on invalidated parts of the AST as it’s being typed instead of waiting for the user to invoke the compiler.

I don't think it comes up in obscure corner cases now with SwiftUI's builder types being concrete, especially with overloaded callbacks like in ForEach

Edit: I just remembered my favorite one: I had a view where the compile times doubled with every alert I added to it.

Re: The Swift compiler is slow due to how types are inferred

#84

Post by josephg »

diffxx wrote: post #70
PaulHoule wrote: post #15

One of the interesting tradeoffs in programming languages is compile speed vs everything else. If you've ever worked on a project with a 40 minute build (me) you can appreciate a language like go that puts compilation speed ahead of everything else. Lately I've been blown away by the "uv" package manager for Python which not only seems to be the first correct one but is also so fast I can be left wondering if it real…

> One of the interesting tradeoffs in programming languages is compile speed vs everything else. Yes, but I don't think that compile speed has really been pushed aggressively enough to properly weigh this tradeoff. For me, compilation speed is the #1 most important priority. Static type checking is #2, significantly below #1 and everything else I consider low priority. Nothing breaks my flow like waiting for compilat…

I think this is a false choice. It comes from the way we design compilers today.

When you recompile your program, usually a tiny portion of the lines of code have actually changed. So almost all the work the compiler does is identical to the previous time it compiled. But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time.

This is quite silly. Surely it’s possible to make a compiler that takes time proportional to how much of my code has changed, not how large the program is in total. “Oh I see you changed these 3 functions. We’ll recompile them and patch the binary by swapping those functions out with the new versions.” “Oh this struct layout changed - these 20 other places need to be updated”. But the whole rest of my program is left as it was.

I don’t mind if the binary is larger and less efficient while developing, so long as I can later switch to release mode and build the program for .. well, releasing. With a properly incremental compiler, we should be able to compile small changes into our software more or less instantly. Even in complex languages like Rust.

Re: The Swift compiler is slow due to how types are inferred

#86

Post by wiseowise »

KerrAvon wrote: post #67
janice1999 wrote: post #59

Earlier quoted context omitted.

Python real strength is the speed it can be taught, read and written.

It’s not, actually, any more than any other language. That was Guido’s original plan, but show a page of modern Python code to someone who’s never seen it before and they’ll run screaming. There is a minimal subset where you can say it reads like pseudocode, but that’s a very limited subset, and, like AppleScript, you have to have a fair amount of knowledge to be able to write it fluently.

It is. Compared to other languages (short of JS without Symbols and async/await/promises mumbo jumbo or lisp) it has much easier entry barrier.

Re: The Swift compiler is slow due to how types are inferred

#87

Post by tines »

ackfoobar wrote: post #53
tines wrote: post #14

Earlier quoted context omitted.

Is it that Haskell, at least, doesn't support overloading in the same way as Swift? I don't know either of them well enough to be sure. It seems like there's a combinatorial explosion of possible overloads in Swift, whereas if you implement a function with the same ergonomics in Haskell (e.g. a printf-like function), the only thing the compiler has to do is ask "Does type X have an implementation for typeclass Show?…

"Does type X have an implementation for typeclass Y" isn't always easy to answer. https://aphyr.com/posts/342-typing-the-technical-interview

That post, while awesome (as is the rest of aphyr's stuff), is a lot to wade through to get to the point you're trying to convey. Can you spell it out for me?

Re: The Swift compiler is slow due to how types are inferred

#88

Post by fweimer »

vlovich123 wrote: post #48

The combinatorial explosion is intractable but since it only seems to come up in really obscure corner cases, I wonder if the typical inference scenarios can be solved by having the compiler cache the AST across invocations so that inference only needs to be performed on invalidated parts of the AST as it’s being typed instead of waiting for the user to invoke the compiler.

I think the challenge here is that it only happens for a type error, not a successful compilation. Each time this happens, the programmer would try to fix the type error, usually invalidating the cache.

I'm not so sure the problem is intractable because it's so well-structured. Someone would have to look at it and check that there aren't any low-hanging fruits. The challenge might be that anyone who could fix this could make much more impactful contributions to the compiler. But it's hard to know without trying.

Re: The Swift compiler is slow due to how types are inferred

#89

Post by TillE »

lolinder wrote: post #77
diffxx wrote: post #70

Earlier quoted context omitted.

> One of the interesting tradeoffs in programming languages is compile speed vs everything else. Yes, but I don't think that compile speed has really been pushed aggressively enough to properly weigh this tradeoff. For me, compilation speed is the #1 most important priority. Static type checking is #2, significantly below #1 and everything else I consider low priority. Nothing breaks my flow like waiting for compilat…

> Nothing breaks my flow like waiting for compilation. With a sufficiently fast compiler (and Go is not fast enough for me), you can run it on every keystroke and get realtime feedback on your code. I already get fast feedback on my code inlined in my editor, and for most languages it only takes 1-2 seconds after I finish typing to update (much longer for Rust, of course). I've never personally found that those 1-2 s…

Yeah even with a large C++ codebase, any decent IDE will flag errors very quickly in real time. I dunno, I've never found that waiting a minute to run a test or whatever is particularly detrimental to my workflow.

I understand the benefits of super fast iteration if you're tweaking a GUI layout or something, but for the most part I'd prioritize many many other features first.

Re: The Swift compiler is slow due to how types are inferred

#90

Post by pjmlp »

janice1999 wrote: post #59
throwaway894345 wrote: post #40

Earlier quoted context omitted.

Most languages are forced to choose between tooling speed and runtime speed, but Python has historically dealt with this apparent dichotomy by opting for neither. (⌐▨_▨)

Python real strength is the speed it can be taught, read and written.

It is an ilusion that Python is like BASIC, in reality Python 3.12 is rather complex, more like Common Lisp, when taking into account all language breaking changes during the last 30 years, its capabilities, the standard library, and key libraries in the ecosystem.
Post reply on HN