About code size

[Kempelen]

Suppose this two pieces of code:

x = 1;
b = 2;
x += b + z;
if (h) 
	x--;
else
	x++;

and:

if (h) {
	x = 1;
	b = 2;
	x += b + z;
	x --;
} else {
	x = 1;
	b = 2;
	x += b + z;
	x ++;
}

In runtime, both executes the same number of instruction, but example 2 is bigger in size, it has 11 lines of code, first one only have 7.

So althought runtime instruction are the same, is code 1 faster because the machine need to copy less execute-instruction each time? (I suppose that a so little example would unnoticiable, but a function with hundred of lines would be different)

(also I suppose a good compiler would optimize the code if correct optimization options are provided).

[CommonTater]

The code is bigger because the program behaves differently.

At run time the source code is gone, simply not there... it's all machine code. Since the if-else construct never executes both if and else, there's no speed hit. The decision has to be made, a jump is executed, the calculations are performed, and the CPU plows off along it's merry way in either example.

There are situations where you can minimize code size or improve performance but for the most part these are rare and bring only marginal improvements. Basically your code has to do what it has to do to get the job done... speed and size generally take a back seat to stability and maintainability...

[Salem]

Common subexpression elimination - Wikipedia, the free encyclopedia
One of many techniques used in modern compilers.

Focus your attention on choosing the best algorithms and data structures for your problem (eg, not using bubble sort for arrays with 1000's of elements), and writing clear code everyone can understand.
Let the compiler worry about the minutiae.

[Kempelen]

The code is bigger because the program behaves differently.

At run time the source code is gone, simply not there... it's all machine code. Since the if-else construct never executes both if and else, there's no speed hit. The decision has to be made, a jump is executed, the calculations are performed, and the CPU plows off along it's merry way in either example.

There are situations where you can minimize code size or improve performance but for the most part these are rare and bring only marginal improvements. Basically your code has to do what it has to do to get the job done... speed and size generally take a back seat to stability and maintainability...

It is clear to me speed is the same. What I am trying to understand is how runtime flow. It is not a issue about programming, but I want to now about how Operating System run the executable, and as I knows, there is a copy of code in memory which system translate to cpu to run instruction per instruction, so I suppose that forgetting the cpu, the operating system need more time to load code into memory each time a function is to been executed, and as function is bigger in size, the copy phase (maybe a memcpy??) would need more time. Am I wrong?

thank you for your unswers. (this is all part of a want to understand how runtime works. if you know of any tutorial or www to understand would be wellcame).

[Kempelen]

Common subexpression elimination - Wikipedia, the free encyclopedia
One of many techniques used in modern compilers.

Focus your attention on choosing the best algorithms and data structures for your problem (eg, not using bubble sort for arrays with 1000's of elements), and writing clear code everyone can understand.
Let the compiler worry about the minutiae.

Salem, thank you very much for your advices, which I take into account. In fact during my last years of development I have been improving data and algorithms, and I see now issues that I want to learn (not necessaryly for improve my program, but having my head with its fornitures is better to design and future actions).

[JohnGraham]

so I suppose that forgetting the cpu, the operating system need more time to load code into memory each time a function is to been executed

The operating system (generally speaking) will only load your code once, not each time a particular section gets executed. But again, this is something you should ignore - modern compilers generally optimize for both code size and speed. Just write what's clearest for you to read as a programmer.

[CommonTater]

It is clear to me speed is the same. What I am trying to understand is how runtime flow. It is not a issue about programming, but I want to now about how Operating System run the executable, and as I knows, there is a copy of code in memory which system translate to cpu to run instruction per instruction, so I suppose that forgetting the cpu, the operating system need more time to load code into memory each time a function is to been executed, and as function is bigger in size, the copy phase (maybe a memcpy??) would need more time. Am I wrong?

Yeah, I'm afraid you are.

You are thinking the source code actually exists inside an executable file... but it's just not there. With C the code you type up on the screen is converted to pure machine code by the compiler then linked into an executable by the linker. At run time the source code is noplace to be found. The executable file, itself is an image of that run-time machine code that is loaded into memory. So the process goes like... create a memory block, load the program image, jump to the entry address... from there on it's all CPU operating directly on machine code instructions in memory.

Actually the source code only exists as a human convenience in creating the machine language image for the CPU...

There are some "Interpreted" or "Managed" languages where the process is pretty much as you describe, where a run time translation of the source code is made by the language. C# and .NET are two examples.

[Kempelen]

Yeah, I'm afraid you are.

You are thinking the source code actually exists inside an executable file... but it's just not there. With C the code you type up on the screen is converted to pure machine code by the compiler then linked into an executable by the linker. At run time the source code is noplace to be found. The executable file, itself is an image of that run-time machine code that is loaded into memory. So the process goes like... create a memory block, load the program image, jump to the entry address... from there on it's all CPU operating directly on machine code instructions in memory.

Actually the source code only exists as a human convenience in creating the machine language image for the CPU...

There are some "Interpreted" or "Managed" languages where the process is pretty much as you describe, where a run time translation of the source code is made by the language. C# and .NET are two examples.

thanks again for the unswer. I knows the difference between compiled and interpreted. Maybe I express myself bad. What I didnt know is how S.O. load the executable into memory. In fact, I dont know why, I thought each time a function is to be executed is copy again into a section of memory. Of course I was wrong, as only once is loaded. What I suppose now is the S.O. make a new data space for the function each time is called (if not, a shared data spece could create conflicts with recursive functions). Again all suppositions......

[grumpy]

Personally, I'd take the original code and make it into

  x = z + (h ? 2 : 4);
  b = 2;

but maybe I'm missing the point of the original question. No mucking around with incrementing and decrementing x. One comparison (of h with zero), an addition, and two assignments.

[CommonTater]

Yes, new data is created each time a function is called. This is actually done on the program's "stack" where the CPU pushs and pops registers for machine language manipulations. Only one copy of the function exists, but each time the function is called it's parameters and any variables created inside are pushed onto the stack then popped back off when the function exits. This is actually done at the curly braces in your source code, creating "scopes" in your program.

[JohnGraham]

What I suppose now is the S.O. make a new data space for the function each time is called (if not, a shared data spece could create conflicts with recursive functions).

Like CommonTater says, that's exactly the situation the stack is used to prevent - if you really want to see how these things work "under the hood" then some assembler programming experience is invaluable. I can recommend "programming from the ground up" is freely available (just google) if you program on Linux.