| > Macros are expanded when you ahead-of-time compile your code, which doesn't take place in the run-time environment where you hot load, but in the build environment. The user experience with hot reload is: 1. They hit "run". 2. The compiler compiles the app. 3. The app starts running on their device. 4. They change some code in their IDE. 5. They click "hot reload". 6. The compiler compiles the changed code. 7. The IDE sends the updated code to the running app. 8. The runtime loads the changed code. 9. They see the changed behavior in their running app. Steps 6-8 determine the total time between "user requests a hot reload" and "user sees their updated app". Compilation doesn't happen on the device, but it still takes time and is in the critical path for that experience. Making the compiler slower makes hot reload slower. We measure hot reload time in milliseconds, so it doesn't take much for us to consider it an unacceptable performance regression. |
Secondly, any compilation delay they experience affects all their iterative development scenarios, including a complete application restart for each run.
If they wrote the macros themselves that are slowing down compilation that much, it is their self-inflicted problem.
Even if macros are slowing down compilation noticeably, unless you change the macros such that everything that uses them has to be recompiled, you still have the benefit of incremental compilation and hot reloading. E.g. recompiling one just one file-with-macros out of hundreds that don't get recompiled.
> We measure hot reload time in milliseconds
It takes seconds to minutes to make the code change, but when you hit the hot-key to deploy it to the target, it's gotta compile and upload in milliseconds?
That's just a silly requirement that will leave your compiler development hamstrung.
I can't even type this comment without at times experiencing character delays that are certainly more than single digit milliseconds. :)
A conclusion like "our users require hot reloads to be milliseconds, end-to-end including compilation" deserves to be researched among the user base, because I don't suspect most devs need the times to be quite that low. They are building a program, not trying to avoid getting fragged in a multi-player shooter!