6 ms·

> Functions should be small + Functions should do one thing This is often a trap for performance. Sure, it looks nice on a screen but calling a function to ret

> Functions should be small + Functions should do one thing This is often a trap for performance. Sure, it looks nice on a screen but calling a function to return a variable is usually epic waste of performance unless compiler will save you by inlining the function into your code or architecture you are using has a magic instruction for that (call vs fcall - which compiler has to recognize and use) which is just fancy "goto there, mov r1 <- *var, goto back"

bluGill 2mo ago
If your compilers is any good it will inline, and do a better job than you of figuring out what should be inlined. For that matter function calls are generally fast so long as the objects you copy as part of the function call are not slow to copy (which they can be). There are exceptions to the above, but in general small functions are not a problem. What is a problem is large functions. I have seen functions that were over 60,000 lines long (and few comments or other excess space takers). I will take a 5 lines max rule for functions (this is nearly straw man levels of short!) over that. Functions that are 50 lines long start to get annoying to read but are not a problem. Even 100 lines functions I can handle. However the extreme of long functions is much worse than the extreme of short.
- rbanffy 2mo ago
  > I have seen functions that were over 60,000 lines long That can't possibly be from a serious person.
  - Jtsummers 2mo ago
    I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, so it wouldn't surprise me if people created ones as big as bluGill describes. The C was almost always written by EEs who learned that function calls were expensive and so they minimized their use of them (this was their stated rationale, not me guessing). What amused me was that every time I tackled one of those things I'd reduce the line count by 70-90%, and usually at least double performance, by using a bunch of small functions to encapsulate the repeated logic. Compilers inline well, and have for quite some time.
    - rbanffy 2mo ago
      > I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, That, spoken by Rutger Hauer.
  - bluGill 2mo ago
    Sadly it is serious and in production code. (I left there 15 years ago, I suspect it isn't in production anymore) Worse, it was a giant switch, and the target system didn't have enough memory for all the code so there were different builds and the user would select which to load. There was code like case foo: doSomething(); #ifdef build_two doSomethingElse(); break; case bar: SomeThing(); #endif MoreThings(); break; Try to follow that mess.
    - rbanffy 2mo ago
      I’m not sure the author knew what was happening. It seems like it worked like this and they left it at that.
      - bluGill 2mo ago
        While this was the worst example he constantly wrote code like that. He could write code like that with few bugs faster than any other programmer I've ever worked with could write code. Management changed between loving and hating him, they knew what his code cost, but they also knew they were getting results fast when that mattered.
        rbanffy 2mo ago
        I knew a guy who naturally wrote code that baffled me all the time. Sometimes I wondered how the compiler managed to figure it out. Fun thing: he was like that all the time - it felt like his language cortex was just wired differently.
- tialaramex 2mo ago
  Manual inlining, like manual loop unrolling wants an explanation, why did you do this, why not let the compiler do it? If I see it with no explanation I am going to assume you don't know what you're doing.
rbanffy 2mo ago
> unless compiler will save you by inlining the function into your code or architecture That's precisely what a compiler should do. Your code should be easy to read and understand. Let the compiler inline calls and unroll loops (until the I1/L2/L3 cache starts becoming a problem, that is)

bluGill 2mo ago

If your compilers is any good it will inline, and do a better job than you of figuring out what should be inlined. For that matter function calls are generally fast so long as the objects you copy as part of the function call are not slow to copy (which they can be). There are exceptions to the above, but in general small functions are not a problem. What is a problem is large functions. I have seen functions that were over 60,000 lines long (and few comments or other excess space takers). I will take a 5 lines max rule for functions (this is nearly straw man levels of short!) over that. Functions that are 50 lines long start to get annoying to read but are not a problem. Even 100 lines functions I can handle. However the extreme of long functions is much worse than the extreme of short.

rbanffy 2mo ago
> I have seen functions that were over 60,000 lines long That can't possibly be from a serious person.
- Jtsummers 2mo ago
  I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, so it wouldn't surprise me if people created ones as big as bluGill describes. The C was almost always written by EEs who learned that function calls were expensive and so they minimized their use of them (this was their stated rationale, not me guessing). What amused me was that every time I tackled one of those things I'd reduce the line count by 70-90%, and usually at least double performance, by using a bunch of small functions to encapsulate the repeated logic. Compilers inline well, and have for quite some time.
  - rbanffy 2mo ago
    > I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, That, spoken by Rutger Hauer.
- bluGill 2mo ago
  Sadly it is serious and in production code. (I left there 15 years ago, I suspect it isn't in production anymore) Worse, it was a giant switch, and the target system didn't have enough memory for all the code so there were different builds and the user would select which to load. There was code like case foo: doSomething(); #ifdef build_two doSomethingElse(); break; case bar: SomeThing(); #endif MoreThings(); break; Try to follow that mess.
  - rbanffy 2mo ago
    I’m not sure the author knew what was happening. It seems like it worked like this and they left it at that.
    - bluGill 2mo ago
      While this was the worst example he constantly wrote code like that. He could write code like that with few bugs faster than any other programmer I've ever worked with could write code. Management changed between loving and hating him, they knew what his code cost, but they also knew they were getting results fast when that mattered.
      - rbanffy 2mo ago
        I knew a guy who naturally wrote code that baffled me all the time. Sometimes I wondered how the compiler managed to figure it out. Fun thing: he was like that all the time - it felt like his language cortex was just wired differently.
tialaramex 2mo ago
Manual inlining, like manual loop unrolling wants an explanation, why did you do this, why not let the compiler do it? If I see it with no explanation I am going to assume you don't know what you're doing.

rbanffy 2mo ago

> unless compiler will save you by inlining the function into your code or architecture That's precisely what a compiler should do. Your code should be easy to read and understand. Let the compiler inline calls and unroll loops (until the I1/L2/L3 cache starts becoming a problem, that is)