We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4863 - Unusually long time in SDL_AllocateRenderVertices
Summary: Unusually long time in SDL_AllocateRenderVertices
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: HG 2.1
Hardware: x86 macOS 10.14
: P2 normal
Assignee: Alex Szpakowski
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.12
Depends on:
Blocks:
 
Reported: 2019-11-17 00:30 UTC by edwinguy
Modified: 2019-11-17 16:00 UTC (History)
0 users

See Also:

Attachments
Flame graph of the call stack (434.70 KB, image/svg+xml)
2019-11-17 00:30 UTC, edwinguy 		Details
Image of what the screen is rendering (1.08 MB, image/png)
2019-11-17 00:36 UTC, edwinguy 		Details
Embarassingly messy code (9.24 KB, text/plain)
2019-11-17 00:37 UTC, edwinguy 		Details
Flame graph when using master branch (878.48 KB, image/svg+xml)
2019-11-17 16:00 UTC, edwinguy 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description edwinguy 2019-11-17 00:30:06 UTC 
Created attachment 4052 [details]
Flame graph of the call stack

I've been playing around with SDL2 bindings for Rust and I decided to look into why my single-core CPU usage is at 54%.

It seems from the flame-graph generated by dtrace is showing the vaste majority of the time is taken up by SDL_AllocateRenderVertices. I looked at the implementation for macOS's Metal and it doesn't seem terribly obvious as I don't expect the time is taken during memory allocation (or that would be a the top). It seems the problem is when changing draw colours.

I've attached the flame graph here (open it in your browser) and I'll see if I can attach a screenshot of what's being drawn along with my sloppy code noodling.
Comment 1 edwinguy 2019-11-17 00:36:41 UTC 
Created attachment 4053 [details]
Image of what the screen is rendering
Comment 2 edwinguy 2019-11-17 00:37:30 UTC 
Created attachment 4054 [details]
Embarassingly messy code
Comment 3 edwinguy 2019-11-17 00:50:40 UTC 
For what it's worth, disabling every call to set_draw_color() (which I presume maps to SDL_SetRenderDrawColor() under the hood) made very little difference.

I also hadn't realized that I wouldn't be able to edit my initial post so pardon the grammar there.

It seems that I'm using sdl2 2.0.10 and the code (which maybe is getting called too many times?) is here:
https://github.com/spurious/SDL-mirror/blob/release-2.0.10/src/render/metal/SDL_render_metal.m#L958
Comment 4 Alex Szpakowski 2019-11-17 07:21:20 UTC 
Are you able to test with the latest SDL source code? I put in a change in August which drastically improved the performance of SetRenderDrawColor on macOS for me.
Comment 5 Alex Szpakowski 2019-11-17 13:33:21 UTC 
Sorry, I meant to say the performance of SDL_AllocateRenderVertices (especially via METAL_QueueSetDrawColor) was improved.
Comment 6 edwinguy 2019-11-17 15:59:43 UTC 
Oh yeah, that made a huge difference. It seems to be about a 5x speedup. I'm now seeing CPU usage of ~12%.

Other than shipping a new build, I'd say this is fixed. I'll upload a new flame graph for the curious.
Comment 7 edwinguy 2019-11-17 16:00:35 UTC 
Created attachment 4056 [details]
Flame graph when using master branch