Love speed comparison

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
User avatar
Jetmate
Prole
Posts: 12
Joined: Sun May 07, 2017 5:48 pm

Love speed comparison

Post by Jetmate »

I recently conducted a speed test between love and Pygame, which runs on Python and is known for being very slow. The test involved drawing a variable number of small rectangles every frame for 100 frames, and then finding the average of the times it took to draw the rectangles every frame. Here are the results:
  • 10 rectangles: Love 0.0004, Pygame 0.0001
  • 100 rectangles: Love 0.0006, Pygame 0.00046
  • 1000 rectangles: Love 0.002, Pygame 0.004
  • 10000 rectangles: Love 0.01, Pygame 0.03
Can anyone explain why Love starts out slower than the infamously slow Python engine, but then, as the work increases, starts beating it? Isn't Lua supposed to be tens of times faster than Python?

As a side note, as I was doing the test, I noticed that even without the sleep function call in the love.run game loop, the framerate still stays at about 60 fps - this is not the case in Pygame. Does Love somehow limit the framerate outside of the love.run function?
User avatar
zorg
Party member
Posts: 3465
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Love speed comparison

Post by zorg »

I think the default setting is that löve forces v-sync; i'd recommend having a conf.lua next to your main.lua, and have the vsync properity be false, for one. That will up the framerate to about 1000FPS (the default love.run limits it to that by using love.timer.sleep(0.001), even without vsync, that is.)

The second thing is, while it's fine if you want to benchmark how fast the framework can push 10-100-1000-10000 commands to the gpu, but if you use a SpriteBatch, add the needed amount of "sprites" into it (which are rectangular meshes with a texture, of course; you can just have an 1x1 pixel Image as the texture though), then call love.graphics.draw(yourSpritebatch) in love.draw, it'll probably be faster with higher number of "rectangles"... though i don't really know if pygame batches rectangle drawcalls or not.

Also, all those numbers you see are within one magnitude of each other, so it may be just fluctuation you're seeing; at least i can't really reason more about that.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
User avatar
Jetmate
Prole
Posts: 12
Joined: Sun May 07, 2017 5:48 pm

Re: Love speed comparison

Post by Jetmate »

You're right that vsync causes the frame delays - I turned it off and the fps instantly jumped.

After doing some more tests, I think I've found an explanation for the initial speed loss: the numerous modules that love loads in the beginning. I turned them off and the speed increased to meet Pygame. But I still don't really understand why Love isn't beating it 10-fold...Is there just an inherent limitation on how fast one can go with graphics?
User avatar
slime
Solid Snayke
Posts: 3162
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: Love speed comparison

Post by slime »

When you draw 10000 separate rectangles, you're actually measuring a bunch of things at once (which makes a benchmark comparison between frameworks not very effective, especially because drawing 10000 separate rectangles is not really a real-world scenario):
  • The CPU-side overhead from Lua's C API which exposes C functions (such as love.graphics.rectangle) to Lua. love uses LuaJIT which is quite efficient, but calling functions which are exposed to Lua using the traditional Lua C API prevents a number of optimizations that calling pure Lua code would get, and the C API has some overhead itself as well.
  • The CPU-side performance cost of love's internal C++ code inside the love.graphics.rectangle implementation.
  • The CPU-side performance cost of 10000 OpenGL draw calls + state changes per frame. This is somewhat dependent on your graphics driver, as that's what implements the OpenGL draw calls.
  • The GPU-side performance cost of 10000 4-vertex draw calls. GPUs are *very* good at processing a lot of things at once. Each separate draw call is only 4 vertices however, which is not many compared to what GPUs are designed for. There is a GPU-side cost for every draw call no matter the vertex count, and then an additional cost due to parts of the GPU sitting idle and not being able to be used, because the GPU wants to process larger numbers of vertices at once than what you're supplying.
  • The GPU-side performance cost due to pixel processing. Every pixel that every rectangle touches on-screen will be processed by the GPU, even when they overlap (the GPU is not able to ignore those pixels, because alpha blending is enabled by default and the alpha value of each drawn pixel is not known to the GPU until the pixel is being processed). If your rectangles are drawn off-screen, or the number of pixels each rectangle touches is reduced, this cost will be reduced.
The costs of #3 and #4 are reduced or completely eliminated if you use a SpriteBatch instead of drawing individual rectangles. love 0.11 (not released yet) will also automatically batch similar draw calls together - effectively using a SpriteBatch internally, in this case.
therektafire
Prole
Posts: 12
Joined: Mon May 22, 2017 3:45 am

Re: Love speed comparison

Post by therektafire »

When will 0.11 be released? And when it is released will all versions be updated at once? I'm stuck using the Google Play Android app runtime version atm 😐...
User avatar
raidho36
Party member
Posts: 2063
Joined: Mon Jun 17, 2013 12:00 pm

Re: Love speed comparison

Post by raidho36 »

The app store version is maintained separately, but it should be updated soon after. You can try grabbing nightly builds and installing them manually.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 5 guests