The dot operator doesn't mean it's slow

Oftentimes, when working in REALbasic, you'll end up using the dot operator as a way to perform some action. If you have experience programming in other languages, this can oftentimes illicit some implications about the performance of the operation. In other languages, the dot operator (or arrow) will cause a method call or dereference to happen. When done in a tight loop, this can sometimes affect the performance of an application. For instance:

for (int x = 0; x < width; x++) {
  for (int y = 0; y < height; y++) {
    int greenChannel = (somePixel >> 16) & 0xFF;
  }
}

for (int x = 0; x < width; x++) {
  for (int y = 0; y < height; y++) {
    int greenChannel = GetGreen( somePixel );
  }
}

It is assumed that in C/C++, the second code snippet will operate slower than the first snippet because of the method call overhead. So, in REALbasic, the assumption is that the following snippet will also be slower because of the method call overhead.

for x as Integer = 0 to width - 1

  for y as Integer = 0 to height - 1

    dim greenChannel as Integer = somePixel.Green

  next y

next x

Well, I'm here to tell you that you don't have to worry quite so much. Not all dot operators in REALbasic have method call or dereference overhead. You see, we are blessed with a smart compiler (and a smarter compiler team, if I do say so myself) that values language consistency over convention. There are plenty of times you use the dot operator without any extra overhead over the more verbose functionality.

For instance, when you use the Color.Red, Green and Blue magic methods, there is no method actually being called. No intrinsic is used there -- the compiler just emits the appropriate bitwise operations to handle it for you. The same thing is true when you use the Ptr datatype. If you call somePtr.Int32( 4 ) = XXX, there's no actual method called Int32 -- the compiler just emits the appropriate instructions to do the pointer operation.

So if you see the dot operator being used by some compiler magic "function", don't always assume there's going to be a performance hit because of it. Instead, you should test and see if there really is a performance implication. Of course, the docs should also point out the places where the compiler does some magic for you so that it's not entirely guess work....