![]() How smart your compiler is: whether it figures many things out without bothering the user with ceremony or constantly requires hints and boilerplate code. ![]() How much your toolchain is optimized, this includes the compiler itself and any build tools you are using.Codebase size: compiling 1 MLOC usually takes longer than 1 KLOC.There are generally three big reasons for long compilation times: Compilation pauses break the flow and make us feel stuck, stopped in our tracks, unproductive. Compilers are smart pieces of software but healthy human work schedules is not what compilers are smart at.ĭevelopers tend to be happier when they feel productive. While both situations arguably have their pros and cons, I believe it’s best to take breaks consciously and not when your compiler tells you to. If time-to-test is too long, you start browsing the social media or get distracted in some other ways, and lose track of what that change you made was.If time-to-test is too short, you are never forced to get some coffee (or a sword fight),.This is often referred to as time-to-test. This post is about one very important aspect of every developer’s life: How long does it take to run a test (or just hit the first line of your program) after you make a change in the code. Let’s start with the obligatory XKCD comic #303 In this post, I’ll tell you about a huge and largely invisible part of Kotlin which makes it compile much faster on relatively small changes that happen a lot in an everyday run-test-debug loop.Īlso, we are looking for Senior Developers to join the team at JetBrains working on fast compilation for Kotlin, so if you are interested, look at the bottom of this post. Compiling a lot of code fast is a hard problem, especially when the compiler has to perform complex analyses such as overload resolution and type inference with generics.
0 Comments
Leave a Reply. |