"cargo check" big-o issue

To investigate "IDE breakdown" problems my team has with their IDEs (that internally use "cargo check"), I did this experiment:

I wanted to know how long a syntax check takes, after making white space changes in 1 file.

I generated a rust project, where each file only calls functions in the "next file":

main.rs -> m0.rs -> m1.rs -> m2.rs -> m3.rs -> ....

Then I timed how much a "cargo check" takes after a "touch main.rs" (a file that is not used by any other file). And I tested this with a different number of source files per project.

Now in C++ etc., the equivalent scales O(1) with the number of source files. "make" determines that only one file has changed, and compiles main.cpp to main.o. The compiler only ever looks at main.cpp. Same performance with 1 source file or 1 million. So the IDE can stay snappy.

Now with rust it gets interesting:

"cargo check" of a new project scales slightly above O(n), as expected.

After I only do a "touch main.rs", the next "cargo check" is much faster, as expected.

BUT: it still scales > O(n) with the number of unchanged files that do not even depend on main.rs:

number of files | seconds
             64 | 2.89
            128 | 5.9
            256 | 11.96
            512 | 26.38
           1024 | 166            <= I think this one hit RAM limits

So here you have numbers on the "IDE breakdown" problem. It is not "hehe get a bigger machine", but a big-O problem that sinks projects.