Skip to content

WIP: Improve ges_layer_add_clip performance

Batch addition of many clips in a loop has various sorting and management stuff show up for around 50% of the total CPU time. This is from doing sorting after each automatic track element priority change, going through the resync_priorities machinery for each, etc. These two patches vastly improve the situation on the premise that the updated data shouldn't be necessary before the timeline is committed, and in fact the commit code already did all this yet again already. After this the GESTrack track elements list isn't sorted thousands of times anymore, and profiling starts showing more logical things as top CPU consumers, like GstElement creations. Adding 1000+ clips still takes over 1.7 seconds, but before this patchset it was 4-6 seconds.

I'm notsure about the removal of the resync on layer priority change, but seemed a logical change too when we are going to assume it all should get sorted out at commit time only.

Edited by Tim-Philipp Müller

Merge request reports