I tried to reproduce this problem in in many isolated ways, (mostly because I can't share all the files)

And I find out that this is just because of armatures and bones.

I attach here the only the bones that we used for trains,
And you can test Toggle Maximize Area in 2.82a and then in 2.83.1, and you will see that is a lot slower.

However, is not as slow as in my video example I share before, because there we have a lot more characters, so I think that for each added character will take even more time.

This armature problem not only slow down Toggle Maximize Area but also when you try to delete something will take more time.
https://youtu.be/OJwsFedIrFA

My intuition is pretty sure that have to do with the the attempt to make the undo faster, and was change the way Blender handle viewport.

I hope someone can look at this matter, because we really want to switch on Blender 2.9 when will be released.
Currently we use blender 2.82a, and we really want that motion blur feature for this tv show.

Thank you for looking into this,

Is actually slow when minimize Area (in Maximize the area is instant always)
I made some tests again with the new Blender build 2.90 31bc76ea4e4b

Here is the test only with trains (the results are the same only with the bones):
https://www.youtube.com/watch?v=_Of8lzgWrCw

Test results:
2.82a = Almost instant to minimize Area
2.90 July 08 31bc76ea4e4b = about 1 second and half to minimize Area
2.83.1 = about 2 seconds and half to minimize Area

The results are more stretched in a full scene with more characters:
https://www.youtube.com/watch?v=URyQ3eWSs00

Here is the clear instructions how to reproduce this:

1. Open the file I have attached before "new Diddlys only bones.blend"
2. Go to View >Area > Toggle Maximize Area, and then press it again,

In T78615#976754, @Germano Cavalcante (mano-wii) wrote:

I can confirm the regression.
It would be interesting to identify which commit resulted in this.
I'm tagging the animation team because a lot of time seems to be spent on evaluating the drivers.
Also tagging the Data, Assets & I/O module since IO is the category that are most using CPU during the test.

@Germano Cavalcante (mano-wii) please do a proper job if you want to tag modules, your last sentence makes absolutely no sense to me. Also if you think a bisecting would be interesting, just do it yourself, since you can already reproduce the issue... Adding a note like that does not help fixing or investigating the issue at all.

In T78615#978082, @Bastien Montagne (mont29) wrote:

@Germano Cavalcante (mano-wii) please do a proper job if you want to tag modules, your last sentence makes absolutely no sense to me. Also if you think a bisecting would be interesting, just do it yourself, since you can already reproduce the issue... Adding a note like that does not help fixing or investigating the issue at all.

Maybe I misunderstood this graph and the IO description

I avoid bisecting since it takes a long time and it would be better if I had an idea which commits may have brought the problem (which is common for developers working in the area).
But I will bisect.

Issue introduced by rB4c30dc343165: Fix T73593: Drivers on hide_viewport and hide_render are unreliable
Here the simplified file:

This is probably related to T77277 then.

Hey Sybren,

I made again the tests with 2.9 last build and I got the same results:

new Diddlys only bones: https://www.youtube.com/watch?v=9UXaSBJBQtM
1.5 second with Blender 2.9 last build.
Almost instant with 2.82a

and full scene test with more characters:https://www.youtube.com/watch?v=kvoM2c2o--Q
6 seconds with Blender 2.9 last build
2 seconds with 2.82a

Thank you for try help us with this big problem.

My apologies, I mixed up my patches -- D8334 hasn't been merged yet, so it makes sense that the performance hasn't changed.

I dug into the original file you attached (F8669945), and I noted that the object "DEE_Rig" has over 28000 drivers. Many of these drivers are defined multiple times for the same property. To see what I mean, try this code:

from collections import Counter
c = Counter(f'{d.data_path}[{d.array_index}]' for d in D.objects['DEE_Rig'].animation_data.drivers)
for driver, occurrence in c.most_common(5):
    print(f'{driver}: {occurrence}x')

This outputs:

pose.bones["ORG-foot.L"].constraints["Copy Transforms.001"].influence[0]: 524x
pose.bones["MCH-thigh_ik_stretch.L"].constraints["Limit Scale"].influence[0]: 524x
pose.bones["MCH-toe.L"].constraints["Copy Transforms"].influence[0]: 524x
pose.bones["MCH-foot_pole_ik_socket.L"].constraints["Copy Transforms.001"].mute[0]: 521x
pose.bones["MCH-thigh_ik.L"].constraints["IK"].mute[0]: 521x

Blender 2.83 solved a problem that occurred when multiple drivers would write to the same memory address. I can understand why this particular file is hit so hard by this, as thousands of drivers are now inspected to detect such problems.

I had no idea the rigging is so bad and have so many useless drivers that slow down soo much.
We need to fix this problem for sure in future and make the rigging more lighter. Thank you for pointing out this problem.

But if Blender can also handle this matter as before would be amazing as well.
Looking forward,

How did you even create this file? Neither the user interface nor the Python API allow the creation of multiple drivers on the same property.

Can confirm is working 100% as before.
Is mind blowing how professional you guys are and how quick you solve this nasty slowdown.
Thanks guys,

@pistol ioan (pistoltoto) Thanks for the confirmation :) I'm still wondering how you got multiple drivers that target the same property. This shouldn't be possible in Blender, and the fact that you could still do this might indicate another bug. If I know how to replicate it, I might be able to fix it.

Translation:

"Hello
I saw your notes on your reported bug
But don't think that I created those problems
Those are all the remaining drivers from all previous attempts
It's from bones that don't even exist anymore
Blender should delete them but don't (bug)
Manually try to delete them and they do not disappear (bug)
So what could I do?
I read somewhere about the bug how blender tries to delete orphaned drivers but goes the wrong way
Wrong path
Yes they missed and so it remains
*misfire
: Slight_frown:
And if you notice, those bones are named after the rigify model
Once there was an attempt to rigify the trains and the mess was left behind"

End of translation.

So basically he say that he try to delete them but he couldn't and they remain there from past attempts to do the rigging for the trains.
Hope this will help,

It doesn't help, as it doesn't answer the actual question (how it was possible to add multiple drivers to the same property). Thanks for trying, though.