Opening this to share first benchmarking results.

no-change: org.scalajs.linker.analyzer.internal.simulateChangedInfo = false
fake-change: org.scalajs.linker.analyzer.internal.simulateChangedInfo = true
optimistic: including second commit

logger-timings.csv

@sjrd I'd appreciate your opinion on this: For the initial linking step, there clearly seems to be a cost to doing this analysis, but there is also clearly a massive speed gain by doing it.

I would expect that dependency preserving changes are not so rare when doing incremental development (especially when fiddling with UI and what not). So to me, this is not very clear cut :-/

I'm still uneasy about this. The situations where it applies are still quite rare. Even for UI tweaking, when it's not CSS-only changes, I feel like calling one method more or less (like putting an additional div() or span()) have the potential to change the infos.

What would be convincing would be an in-situ noticeable difference. Try with and without the changes, on a real(-ish, possibly demo) codebase, making small changes and test whether it feels any faster. If the difference can be perceived in situations where it matters, that would make a good case for this optimization.