|
|
View previous topic :: View next topic |
Author |
Message |
foxOnTheRun
Joined: 17 Apr 2010 Posts: 43
|
Code optimization: cascade of IFs statement vs switch..case |
Posted: Sun Jan 29, 2012 4:06 am |
|
|
Hi, using compiler 4.124 and in the code I have:
Code: | if (stage == 0) t1++; // stage fast 160ma
if (stage == 1) t2++; // stage slow 80ma
if (stage == 2) t3++; // 40ma
if (stage == 3) t4++; // 20ma
|
That is a mutually exclusive check, I expect to have true just one of them so I decided to substitute it with:
Code: | switch (stage) {
case 0: t1++;break;
case 1: t2++;break;
case 2: t3++;break;
case 3: t4++;break;
}
|
Because it's the right way to approach to this kind of check.
But compiling I get an increased filesize of the .hex file: 22.425 byte (IFs) vs 22.405 byte (switch..case).
Now, I'm in a tight memory condition and I'm shaving off the code here and there trying to squeeze every byte that could be recovered (removing unecessay white spaces from printfs, doing variable assignement between same type, removing excess of variable zeroing and so on..).
Is it normal that with the right program structure the code actually increse size? is there any documentation available describing compiled memory use vs C structure as reference?
Thx :) _________________ Listen, why don't you relax? Take a pill, bake a cake or go and read the encyclopedia. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19512
|
|
Posted: Sun Jan 29, 2012 4:17 am |
|
|
The rules may well have changed, but used to be that if you generate a switch with four or more entries, and no 'default' statement, the compiler changed to generating a jump table, rather than doing the individual tests. This is much _quicker_ as the number of entries increases, taking exactly the same time to get to every entry in the 'switch', _but_ for a small number of cases, will be bulkier (there is the setup code to access the table). If you did the same comparison with (say) fifteen cases, the jump table ought by then to be the smaller code as well.
The only real way to find out what code generates what size, is to test. One might say (for example), set the timings as an array, and use:
t[state-1]++;
However this too uses table accesses and would probably be slower and bulkier....
Code generation changes depending on 'circumstances', with exactly the same code in two places, giving different sizes, depending on things like the need to bank switch because of the code in front of and behind a particular section.
Best Wishes |
|
|
foxOnTheRun
Joined: 17 Apr 2010 Posts: 43
|
|
Posted: Sun Jan 29, 2012 4:55 am |
|
|
All right, I understood your explanation, thanks.
This explains also why somewhere in the code a:
would give less compiled filesize than:
But not all the times :eek:
.. yes, I'm really that low on freespace :cry: _________________ Listen, why don't you relax? Take a pill, bake a cake or go and read the encyclopedia. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9226 Location: Greensville,Ontario
|
|
Posted: Sun Jan 29, 2012 7:16 am |
|
|
The lament of the programmer..NEVER enough space !!
You probably already know but...
If you use floating point numbers, try to get rid of them and use integer math...that will free up some space...
Guess you can't put a bigger PIC in...sigh... |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19512
|
|
Posted: Sun Jan 29, 2012 8:09 am |
|
|
Another thing that can save a _lot_ of space, is combining printf's.
In your post, you mention two printf statements, one with %3Lu, and one with %4Lu. If you had a single statement in a subroutine, using the %4lu format, and then called this in both locations, this would take significantly less code space than having the two separate statements. If you can 'get away' with having one more space in the first printf, it could help. Do this with a number of different printf formats, and you can save a lot of space....
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|