Is your test patch anywhere ready to test? (preferably not "go here to download the whole library, then go there and do this, ect.")
Here a set of patches that aim to illustrate my findings: https://netpd.org/~roman/tmp/illustrate-ds-redraw.zip
First open 01-illiustrate-redraw-with-many-scalars.pd. It will draw 1600 lines that are overlapping, so that the redraw is clearly visible.
Then open the other patches. Depending on how they are created, they trigger a redraw at load time. Read the comments in the patches.
It takes exactly 3 seconds to redraw 1600 scalars on my machine. I wonder if it takes longer on Windows (that's what some reports suggest).
Redraw times when opening patches (counted in my head):
2 - 15s
3 - 0s
4 - also around 15s, this seems to be the reference value no matter
which other patches are opened.
This on W10, Thinkcentre, 2x2Ghz, 16Gb Ram.
Opening and closing my help patches when your patch is open also causes a redraw (same duration as above) or hangs Pd for a while. This surely because they also use $0-names in the templates.
The delay on other gui objects is normal, is just pd overloading the system with anything gui-related.
That's what I've been thinking for years and now I'm starting to believe that the redraws are unnecessary and avoiding them could be possible. What I'm struggling right now is how to create re-usable abstractions that use data structures. Using $0 in struct names seems to always force a redraw. So, I'm trying to find a way around that. If replace all instances of $0 in a ds patch with a random number, loading it doesn't trigger a redraw. What makes $0 special?
Couldn't say it, as I don't know anything below the surface of pd. Maybe some problem assigning/reading the $0 into the templates.
You could also try to use $0 as parameter for scalars or template arguments, but not in the template name, to see if that makes a difference.
It seems to me that gui peformance has gotten worse in 0.53.1, but I haven't been using Pd enough to pinpoint it. If affects mostly GOP and loading/closing speeds, maybe not related with this.
My subjective sense is similar, but I haven't actually verified it. However, the lag caused by loading patches with data structures has been bugging my for years, way before 0.53.1, I just wasn't able to pinpoint it before.
My clicktracker patch (which is one GOP object) takes ages to load now, it wasn't like that a couple of months ago. (nothing changed in it during this time)