Hacker News Reader

That honestly feels like a minor problem, and not something to optimize for. Also an aggressively inlining compiler will experience exactly the same problem. AFAIK at least clang always inlines a static (as in internal linkage) function if it's used only once in the translation unit, no matter how large it is.

View on HN

Visual studio doesn't do that inlining. And it is a significant problem, I have had to refactor my code into multiple functions because of it.

It might be a significant problem, but not in the code, but the compiler. Fair enough, you are working around a compiler issue.

If you consider any superlinear complexity a 'compiler issue' I guess.

It absolutely is, if it makes compile times unreasonable for reasonable code. Compilers have to make trade-offs like this all the time, they can't use overly excessive optimizations.

I dunno. O(n^2) is for sure a bug. But O(nlogn) I think is reasonable.

O(nlogn) is probably reasonable. Why break up a long function then if you are experiencing O(nlogn) scaling of compile time on function size?

Because it can still result in compile times I find excessive. For example breaking up a function that takes 5 seconds to compile into a bunch of functions that take 1 to 2 seconds in total.

Reply on news.ycombinator.com