[noxToken]

If it's not a function of the size of the code, then what does build time map to? I understand that dependency management, effective testing, proper build configs, etc. also factor into that function. I also understand that size of the code does not have to be a linear scalar, but it seems that a constant hard limit is very arbitrary.

I'm really not trying to crap on your decisions. I just want to know the rationale behind it. There are projects where everything is written in house with 10K lines of code. There are behemoths with 500k+ LoC and numerous dependencies. How does this factor into the decision?

[markoa]

Oh, I meant that "size of the code does not have to be a linear scalar". Also by hard limit I didn't mean that the build should auto-fail or anything (sry English is my 2nd language).

But if we have a rule of thumb, we can know when it's time to start thinking about optimizations.

Code size is certainly a factor but it doesn't have to imply constant time increase. Speaking from experience in web apps, optimization of setup (whatever needs to happen before first test runs) + more parallelism + thinking more about decoupling is usually the right answer.

The point of these discussions is mostly to help people avoid ending up with a single 500k+ LoC behemoth.

[BuuQu9hu]

Hi! Unfortunately, compilers must take at least linear time to compile code, because they must examine every character. Ditto for pretty much any serializer. Also, you'd think that the number of LoC matters, but the choice of language matters too; look how long it takes to compile terse high-level languages like Haskell. Finally, as you probably already know, many steps of a build are non-parallelizeable, and as others have already pointed out, even a task like linking a binary can take multiple minutes at scale.