Thanks for the benchmark, but your example is not using the SDL_LowerBlit.
I did my own testing at home using SDL_LowerBlit and got similar results,
meaning there is little difference between SDL_BlitSurface, and
SDL_LowerBlit when all inputs are valid and optimal.  As my use case has
checked all the boxes for requiring optimized/lower-level blits (many small
blits for small surfaces, all valid parameters without need to check each
time), I felt compelled to test it.  I will consider different approaches.

On Mon, Mar 14, 2016 at 5:19 PM, Peter Finlayson <frnkn...@iafrica.com>
wrote:

> Well, if it gives you any satisfaction... I am not a pygame-team
> developer, but Ubuntu makes building this stuff easy-ish.
>
>
> I wrote a quick test script, using cProfile for timing information. I
> stripped almost everything out of the blit call, both in PySurface_Blit()
> and surf_blit() which calls it.
>
> *Results with blit()*
>
> 372532 function calls (370644 primitive calls) in 13.809 seconds
> ncalls  tottime  percall  cumtime  percall filename:lineno(function)
> 288000    8.232    0.000    8.232    0.000 {method 'blit' of
> 'pygame.Surface' objects}
>    600    5.080    0.008    5.080    0.008 {pygame.display.flip}
>
>
> *Results with unsafe_blit()*
>
> 372532 function calls (370644 primitive calls) in 13.899 seconds
> ncalls  tottime  percall  cumtime  percall filename:lineno(function)
> 288000    8.231    0.000    8.231    0.000 {method 'blit' of
> 'pygame.Surface' objects}
>    600    5.125    0.009    5.125    0.009 {pygame.display.flip}
>
>
> Sorry, guys. There really wasn't much there to strip out. Just a couple of
> if statements.
>
> Here is are the C functions I used:
> https://bitbucket.org/snippets/frnknstn/bKqAz
>
> Here is the test Python code I used:
> https://bitbucket.org/snippets/frnknstn/dKqAr
>
> Regards,
> Peter Finlayson
>
>
>
> On 2016/03/14 08:55 PM, Leif Theden wrote:
>
>> Thanks for taking the time Peter to do this benchmark, but I don't
>> believe that
>> this is testing the overhead that exists in the pygame C code.  To
>> clarify, your
>> benchmark is slightly contrived in that it is doubling the python
>> workload, when
>> I am interested in seeing the results of getting lower to SDL blitting.
>> I get
>> your message, I am absolutely clear that python is generally the
>> bottleneck.  If
>> you can find a way to isolate and test the following parts of the C
>> extension
>> library, I would be happy to see the results.
>>
>>
>> https://bitbucket.org/pygame/pygame/src/d61ea8eabd56025fcb4ceb24d63f9a6a30fbe8d4/src/surface.c?at=default&fileviewer=file-view-default#surface.c-2988:3114
>>
>>
>>
>> On Mon, Mar 14, 2016 at 12:06 PM, Peter Finlayson <frnkn...@iafrica.com
>> <mailto:frnkn...@iafrica.com>> wrote:
>>
>>     On 2016/03/14 04:35 PM, herve wrote:
>>
>>         before being a skilled pygame developer, there is a newby
>> developer and
>>         _maybe_
>>         giving him good performance for simple things will let him stay
>> and
>>         growing to
>>         skilled developer.
>>
>>
>>     A newbie developer seeing a "faster" unchecked function, trying to
>> use it,
>>     and then getting discouraged when it inevitably fails... That is
>> exactly why
>>     unsafe_blit() is a bad fit for Pygame.
>>
>>     If you want a quick benchmark to show you are barking up the wrong
>> tree, you
>>     can do one at home, with no C experience needed! Take some game code
>> you
>>     wrote, and run it three ways:
>>
>>     1. Once unaltered
>>     2. Once where you run the sprite update code twice (logic, movement
>> and physics)
>>     3. Once where you draw every sprite twice
>>
>>     Record the FPS every time and see if that shows you where the real
>>     bottleneck lies. Here are the results I got from one of my projects:
>>
>>     1. Base:        125 FPS
>>     2. Double logic: 75 FPS
>>     3. Double draw: 115 FPS
>>
>>     I had to take the game all the way up to 6x draw calls per frame
>> (4000+
>>     blits!) before I got it down to the 75 FPS mark.
>>
>>     The point here is that if I was writing a game to have even double the
>>     sprites I do now, the game logic overhead would be the problem. Even
>> if the
>>     unsafe_blit() magically doubled the speed of my draw routines, it
>> would have
>>     little effect on my overall frame rate.
>>
>>     Regards,
>>     Peter Finlayson
>>
>>
>>
>

Reply via email to