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 >> >> >> >