Here's my use case: For testing Amper, I use it on...

# amper

[Jakub Gwóźdź]

Here's my use case: For testing Amper, I use it on unimportant projects like puzzle contest (Advent of Code, Everybody Codes, etc). And those projects have one thing in common: each new day/puzzle is a separate main() that I run just from IntelliJ (ctrl-r or click-the-green-triangle).
And I noticed one thing: when there is a relatively small number of such files, each run is rather quick, but as soon as it grows, the delay became more and more noticeable and inconvenient. Even if between each run I just edit a tiny bit of code in one tiny file not really connected to rest of the project, it looks like Amper plugin is rebuilding everything?
You might want to look more closely to this at some point 🙂

[joffrey]

Yes, we are aware of this. We just haven't implemented incremental compilation within a module yet. Have you tried putting each day/puzzle in a separate module? The current compilation avoidance should generally solve the problem this way.

[Jakub Gwóźdź]

ah no I haven't, for now I can live with how it is 🙂 especially if you're aware of the thing and will get to it eventually 🙂

[christophsturm]

does that mean amper always compiles all sources within one module? (all main sources or all test sources)

[joffrey]

Yes, sort of. For each module, there are nPlatforms * 2 compilations: main and test for each platform. Each compilation works with its own set of fragments. For example, the iosArm64 main compilation will compile src, src@native, src@apple, src@ios, and src@iosArm64 together, while the jvm test compilation will compile test and test@jvm together. So technically it is slightly more granular than entire modules.

We have some incremental cache that protects each compilation: if its sources, settings, dependencies, and output classes haven't changed, we don't recompile. If anything changed we recompile the (entire) corresponding set of sources (this is where real incremental compilation will play a big role).