which is more efficient? using -> or . to access array of struct members

I need to code for execution speed and wondering for an array of struct, is it more efficient to do

arraytype *a = &myarray[0];
a->fld1 = x;
a->fld2 = y;

or
myarray[0].fld1=x;
myarray[0].fld2=y;

or is there no difference?

this is code inside ISR so I need it to execute in least possible time.
thanks

Write both bersions and examine the code generated. The compiler is quite smart, and will usually mak efficient code irrespective of the way you have written what is syntactiaclly differenet but semantically (almost) identical

Enable verbose verification in the Preferences dialog

The temporary directory is revealed (and the file compiled with more switches?)

Example:
C:
cd "C:\Documents and Settings\Michael\Lokale indstillinger\Temp\build1839547722083701602.tmp"

Execute the avr-objdump from the arduino directory. -H for help (Path for Win7 and XP)

"C:\Program Files (x86)\arduino-1.0.5\hardware\tools\avr\bin\avr-objdump -S filename
pipe to file

For a single module. (jumps outside module undefined) use the file.cpp.o
For the whole program -S file.cpp.elf

obj-dump outputs the assembler code right?

another question is.

if I have something like

x = a->fld1+2;
y= a->fld1/2;
and so on...

would it be more efficient to just do

i = a->fld1;
x=i+2;
y=i/2;

I suppose looking at the assembler code will give me the answer, but I ask here in case someone knows the answer already.
thanks

Msquare:
The compiler is quite smart, and will usually make efficient code irrespective of the way you have written

The precise circumstances on when it can optimize away your "long way round" of writing code (long way, but more clear) and the short code depends on too many subtle factors for me to simply answer the question. So - Try it

a = (test>3)?0:test+1; These two usually generate the same code

if (test>3)
  a = 0 ;
  else
  a = test+1;

yeah its hard to tell.

I suppose if the generated code size is exactly the same, that means there is no difference.

On my actual program, using myarray*.field1 generated a smaller code size, but not by much. 3156 to 3148.*
I'm assuming that is 8 extra machine code instruction?
let's say it is. This is on 4 PWM timer interrupt service routines that get called once every 1024us each (each of the 4 ISR is invoked once every 1024us). I suppose that is not significant difference to worry about.

strange, if I call another function passing the array index number so the called function will just access the array directly via the index (array is volatile global ), the compiled size is 66 bytes larger.
my original code is to pass &myarray* to the function, then the function accesses the field as myarray->field1*
changing to pass i as parameter, then the function access via myarray*.field1 resulted in a larger compiled size.*

Smaller code size does not necessary mean faster.

With performance the proof is always in the pudding test (imho).
Write a small sketch and time 500 times you construction
do the same 1500 times and the difference is the time 1000 instructions take (without loop overhead)

true.

is arduino compiler set to optimize for speed or for size?

if it is optimized for size, where do I switch it to optimize for speed.

looks like its optimized for size

http://forum.arduino.cc/index.php/topic,86810.0.html

I guess I'm splitting hairs here at this point.
maybe when I end up needing to make a lot of floating point operations inside an ISR, then I will have to revisit this.

robtillaart:
With performance the proof is always in the pudding test (imho).

Pardon me, but this is one of my pet peeves: the proof of the pudding is in the tasting. That's the saying. You could also say, the proof of the code is in the benchmark.

I guess I'm splitting hairs here at this point.
maybe when I end up needing to make a lot of floating point operations inside an ISR, then I will have to revisit this.

No need to revisit it since you shouldn't be doing any floating point operations in an ISR. They are very costly on an arduino whcih has no hardware floating point.

I'm doing waveform generation. right now my code does not have floating point operation, but there might be a need for one sine function call, does not have to be done on every single interrupt, but has to be done at some interval, so I guess "a lot" was not the right choice of words.

sine != floating point.

is arduino compiler set to optimize for speed or for size?

Size, supposedly. But it doesn't seem to do a great job of making correct decisions. For example, I've seen it decide to inline small functions in small programs (getc() in the bootloader) such that the program becomes significantly larger. I think it makes its "size" judgments based on some intermediate code representation rather than after the final conversion to AVR instructions is done (and AVR violates its assumptions about how big things are in several ways.)

did some "integer sin " exploarations here - A faster sin() lookup function. - Libraries - Arduino Forum -
might be useful

@doughboy
Can you tell more about the goal and how your code looks like (post it) . Probably we can help optimizing.

robtillaart:
did some "integer sin " exploarations here - A faster sin() lookup function. - Libraries - Arduino Forum -
might be useful

@doughboy
Can you tell more about the goal and how your code looks like (post it) . Probably we can help optimizing.

interesting. actually, if I use sin, it will be simpler, since this is for 8 bit pwm, I only work with values up to 255. I can divide the cycle into 360 resolution (1 degree can be as low as 2ms, since pwm freq is 490hz), and as high as 28ms.

the formula is (using degrees instead of radians). since isin does the %360, I can pass in the 16bit parameter as is.
value = 128 + 127 * isin(degree);
value is unsigned 8 bit

do you see a way to optimize your function for this usage? perhaps return as signed integer (-255 to 255) without dividing by 255, and do the /255 outside the function to make it truly floating point free? or as in earlier discussion, will the compiler optimize the code into all integer operation?

come to think of it, I can probably just map the whole function into a table, and maybe lower the resolution down to 255 or even 128 from 360. That will be a 255 (or 128) byte lookup table though.

something like this?

uint8_t isinTable8[] = { 
  0, 4, 9, 13, 18, 22, 27, 31, 35, 40, 44, 
  49, 53, 57, 62, 66, 70, 75, 79, 83, 87, 
  91, 96, 100, 104, 108, 112, 116, 120, 124, 128, 

  131, 135, 139, 143, 146, 150, 153, 157, 160, 164, 
  167, 171, 174, 177, 180, 183, 186, 190, 192, 195, 
  198, 201, 204, 206, 209, 211, 214, 216, 219, 221, 

  223, 225, 227, 229, 231, 233, 235, 236, 238, 240, 
  241, 243, 244, 245, 246, 247, 248, 249, 250, 251, 
  252, 253, 253, 254, 254, 254, 255, 255, 255, 255, 
  }; 

int isin(long x)
{
  boolean pos = true;  // positive - keeps an eye on the sign.
  if (x < 0) 
  {
    x = -x;
    pos = !pos;  
  }  
  if (x >= 360) x %= 360;   
  if (x > 180) 
  {
    x -= 180;
    pos = !pos;
  }
  if (x > 90) x = 180 - x;
   if (pos) return isinTable8[x]/2 ;
  return -isinTable8[x]/2 ;
}

returns a val between -127and 127

doughboy:
come to think of it, I can probably just map the whole function into a table, and maybe lower the resolution down to 255 or even 128 from 360. That will be a 255 (or 128) byte lookup table though.

Be careful. Depending on which Arduino board you are using, tables like this can quickly run you out of SRAM. I had two 100-byte lookup tables once, and then I decided to increase the resolution to 256-bytes each, and my program started crashing because it was running out of SRAM. You might want to look into using the progmem() keyword and its associated functions if you are working on a board with not much SRAM (Uno, for example) and have many large tables.

You can put the table into PROGMEM at the cost of one more clock cycle to access an element.

Meanwhile some of you guys might want to edit your posts on page 1 and use code tags. The posts that jump into italics half-way through are a clue you are referring to [i] in them.

Not only is the italics distracting, the code makes no sense when the [i] disappears.