Significant slowdown in deleting clips w many clip timelines

Two identical timelines: 500 x 1 second clips, delete the first one.
(And don't you dare suggest it's a codec issue. It's not!)
In DR 18.5.1: 1,5 second delay
In DR 18.6: 11,5 second delay

Evidence:
18.5.1:

18.6:

The grey clips: https://drive.google.com/file/d/1G2vYo- ... sp=sharing (expands to 1,5 GB, I made 7200 test files)

Turns out there's a big difference in terms of the delay sub 200 clips and above 200.

Turns out there's a big difference in terms of the delay sub 200 clips and above 200.

That's a very interesting discovery. You wonder what the magic is with 200 clips?

One of the reasons I use a 256GB machine is to load all the timelines at once, and (in general) it does make for faster Resolve sessions, because a good chunk of it is loaded into memory at startup.

I tried with 500 clips and I had around 12 seconds delay after ripple delete.
If you remove all linked audio clips, the delete is instant.

Turns out there's a big difference in terms of the delay sub 200 clips and above 200.

That's a very interesting discovery. You wonder what the magic is with 200 clips?

One of the reasons I use a 256GB machine is to load all the timelines at once, and (in general) it does make for faster Resolve sessions, because a good chunk of it is loaded into memory at startup.

Then you have not understood the problem.

It is an algorithm issue, not a computer specification problem.
The sorting/moving has changed between the two versions, as that's the only difference between the two videos.
I just realized it's even worse than I wrote: The 18.6 is on a 13400F while 18.5 is on a 6800K. Meaning the 18.5 has significantly slower compute power than 18.6.

And with regards to the 200 number? No idea. Probably a <200 clip is algorithm1, >200 is algorithm2 thing, but I don't know
I fear it's an O(n) operation (and single threaded) whereas it should be a O(log(n)) or lower
(Edit: Just realized that not everyone understands Big O Notation:
https://en.wikipedia.org/wiki/Big_O_notation
Example:
https://en.wikipedia.org/wiki/File:Comp ... lexity.svg

All this with one audio track in the timeline:

Locking audio track: instant delete
Unlinking video+audio, then Delete selected video clip(with backspace): instant
Unlinking video+audio, then Delete selected audio clip(with backspace): instant
Unlinking video+audio, then Delete (with delete): delay
Delete empty space in timeline (with backspace OR delete): delay
Edit -> Delete gaps: Delay

Same here, i7-8700k, RTX 3060ti
MASSIVE performance regressions on my timelines

same here in windows 11 as well. Was expecting black magic to fix it by now

Seems identical to my issue, could you confirm?

viewtopic.php?f=21&t=184584

Seems identical to my issue, could you confirm?

viewtopic.php?f=21&t=184584

Really? You never mentioned having 200+ clips on your timeline. That could be a clue.

Seems identical to my issue, could you confirm?

viewtopic.php?f=21&t=184584

Really? You never mentioned having 200+ clips on your timeline. That could be a clue.

I didn't expect that needed to be said considering the video literally shows this...

Thanks - I never noticed that in the image but that's a great clue to corroborate Mads' observation!

What would be additionally useful is if you could test with fewer than 200 clips and report if the ripple delete is without delay. Are you willing to test and report on this? That would be very helpful.

Thanks - I never noticed that in the image but that's a great clue to corroborate Mads' observation!

What would be additionally useful is if you could test with fewer than 200 clips and report if the ripple delete is without delay. Are you willing to test and report on this? That would be very helpful.

Same clips as before, I might have overestimated how fast it was. Still in the ~1.5 second range

I was speaking to Dan, actually - he reported this slow-down with over 400 clips - I'm wondering if he could duplicate the timeline and remove all by just fewer than 200 clips and test that it speeds up to (as you observed, 1.5 seconds or better).

Might be related to My performance issues as well:
viewtopic.php?f=21&t=188396

I just realized it's even worse than I wrote: The 18.6 is on a 13400F while 18.5 is on a 6800K. Meaning the 18.5 has significantly slower compute power than 18.6.

Does this mean the two tests are on two separate systems?
I don't think performance of your project databases have too much to do with your processor speed given that the processor is not a potato. It will usually have more to do with the speed of your storage device, specifically how it handles a database workload.

What database type do you use for your projects? I have noticed snappiness of certain actions like ripple delete on a large timeline or pasting a grade to many clips take a proportional time to the ability of the database the project is working out of. The biggest unresponsive delays being Blackmagic Cloud database(but that is to be expected with latency over the internet) I use a MacMini dedicated to be a local Project Database with the database on an SSD and it performs the same action of pasting grades that I mention above (about 10 seconds on a cloud database) reduces to an unnoticeable delay when working on our local network database. And of course for a Disk Database or running a network database on the same computer as Resolve, it performs as you would expect for the storage medium the database is on minus any background activity eating up performance on your computer.

Separately have you enabled Multiuser Collaboration? I have noticed that with identical conditions with multiuser collaboration enabled for the project, the same actions add a tiny bit but noticeable amount of delay compared to the project with collaboration not enabled.

And if all is the same, maybe some default of how a project interacts with its database might have changed between 18.5.1 and 18.6?

Does this mean the two tests are on two separate systems?
I don't think performance of your project databases have too much to do with your processor speed given that the processor is not a potato. It will usually have more to do with the speed of your storage device, specifically how it handles a database workload.

What database type do you use for your projects? I have noticed snappiness of certain actions like ripple delete on a large timeline or pasting a grade to many clips take a proportional time to the ability of the database the project is working out of. The biggest unresponsive delays being Blackmagic Cloud database(but that is to be expected with latency over the internet) I use a MacMini dedicated to be a local Project Database with the database on an SSD and it performs the same action of pasting grades that I mention above (about 10 seconds on a cloud database) reduces to an unnoticeable delay when working on our local network database. And of course for a Disk Database or running a network database on the same computer as Resolve, it performs as you would expect for the storage medium the database is on minus any background activity eating up performance on your computer.

Separately have you enabled Multiuser Collaboration? I have noticed that with identical conditions with multiuser collaboration enabled for the project, the same actions add a tiny bit but noticeable amount of delay compared to the project with collaboration not enabled.

And if all is the same, maybe some default of how a project interacts with its database might have changed between 18.5.1 and 18.6?

But if it was a database problem, why would disabling sound create such a drastic effect?
That alone makes me think it's purely a change in the timeline code.
And yes, I have a resolve 18 on the 6800K and 18.6 on 13400F, because of unimportant historical reasons.
And I never mentioned databases Because they are not relevant to the issue at hand (IMO)

18.6 has been much slower than 18.5 with timeline manipulation.

I reverted to 18.5 (for this and many other issues) and it's back to the speed I was used to.

viewtopic.php?f=21&t=188348&p=983245#p983243
Playback -> Timeline proxy resolution -> quarter (even if no timeline proxy exists) lessen the impact, but doesn't solve it entirely.

I just realized I didn't tell why I think it's a algorithm problem:
If you delete the first clip in a timeline with many clips to the right, it's slow, but if you delete a clip with few clips to the right, it's fast.
So the bug is in "the moving clips to the left" function

I can confirm this bug on my MacBook with 18.6 Studio. When I delete a clip on the edit page, it takes a very long time to delete and then ripple the timeline and if I move to Fairlight I can see that the Fairlight timeline did not ripple. This was with 250 clips on V1/A1 - Simple 1080p H264. On 18.5.1 Studio, delete and ripple of the same project was instantaneous and no desync of audio.

Update - Should mention that I was deleting the first clip on the timeline of 250 clips. The further along (toward the end of the timeline) the shorter the delay (to Mads' point regarding sort algorithm).

Warning - I haven't seen anyone else post this observation but if I put a mark In/Out on a clip on the edit page and then move to Fairlight, it is clear that the In/Out in Fairlight do not align to the supposed clip boundaries there - it's not that the playhead is different in terms of media playback - it looks to me like Fairlight has incorrect clip boundaries marked. Hard to describe but simple to see - probably at the root of why the desync occurs when ripple-deleting a clip. Seems like if I move the boundary of a clip on the Fairlight page the clip boundaries shift to match those on the Edit page (although this doesn't fix the desync with ripple delete on the Edit page).

The fact that not all users see this is a real mystery.

I should state that the way I created this timeline was with Scene Detect on a 3-hour H264 media segment (because it's all I had on had) which means that each clip is really a sub clip of the original media. Not sure if that makes a difference so I'll continue testing. Cheers.

Update - Tried with a normal timeline of many (>200) clips (not from a Scene Detect) - it has the same issue. Bummer.

I can confirm that a ripple delete on Edit page does not flow to Fairlight page. It leaves a gap in the fairlight page clips with all subsequent audio clips having a red bar to the bottom right. Audio is then out of synch for all subsequent clips.

This is preventing me from proceeding with my project, so I will revert version now.

Just tested on Linux using the DRA above and exact same thing with the delay.
And also fairlight vs edit page discrepancy.

Switching to another timeline then reloading the timeline with all the clips seems to also fix the issue. (fairlight shows the right thing)

Just tested on Linux using the DRA above and exact same thing with the delay.
And also fairlight vs edit page discrepancy.

Switching to another timeline then reloading the timeline with all the clips seems to also fix the issue. (fairlight shows the right thing)

This is a lifesaver! Thank you! I have same issue on Mac Studio. It started on all computers in our studio yesterday. We have been using Resolve 18.6 since it was released (for about a week) and since yesterday we have issues when performing ripple delete action on longer timelines. The solution we will stick with for now - switching between timelines. Thank god, we do not have to restart Resolve every time this happens.

But what I noticed after switching timelines, undo does not work with a shortcut. It only works when I choose the action under History section on top menu system.

[Peter Chamberlain]

Please see if 18.6.1 resolves the issue you have with 18.6.

Please see if 18.6.1 resolves the issue you have with 18.6.

It works as in 18.6.1

Excellent work to everyone involved!
Please bring my praise and eternal admiration to the dev team.

Please see if 18.6.1 resolves the issue you have with 18.6.

That was bloody quick, Peter! Thank you and all your team behind Resolve. It really felt like an overnight fix. I can confirm that this issue is no longer present.