I also agree with Greg. My experience tells me that, in order to have a significant overhead, you must have a loop.
Overhead that doesn't modify the O performance value are caused in most cases by loops whose number of iterations are independent of the input size. Checks alone are very unlikely to cause a significant overhead. In C and x86 architecture a simple if compiles only to 2 or 3 bytecode instructions.
On 13 March 2016 at 23:22, Greg Ewing <
greg.ewing@xxxxxxxxxxxxxxxx> wrote:
> Leif Theden wrote:
>> The fast_blit method would with the barest minimum of checking before
>> calling the sdl blitting functions.
>
> Have you performed any measurements to find out whether
> the checking overhead is significant in the cases where
> the formats do match? Without evidence, I'm skeptical
> about that.
I agree with Greg, the checks themselves are very unlikely to take a
significant amount of time.
I think Leif is right though that the forgiving nature of the blit
functions makes it easy to have horrible performance problems in your
code and to be completely unaware of them. How about adding a thing to
print warnings about issues like this?
You'd something like this to your game:
 pygame.set_performance_warnings(True)
And then in the blit code, there would be extra stuff like this:
 if (src->format != dst->format) {
  if (performance_warnings)
   printf ("** performance warning: bit: src and dst formats do not
match\n");
  format_convert (src, dst->format);
 }
ie. it would warn you that extra conversions were being done behind your back.
Now to speed up your game, you just need to turn on the warnings and
try to stop your inner loops printing things. No doubt other parts of
pygame do similar things to this.
I'm a C programmer, I'd be happy to make a small patch to add
something like this if there's interest.
John