Hey,
I actually just dropped in to ask if anyone else experienced long loadtimes when opening a large patch?!?

..of course it should take longer the more objects have to be loaded,
but I recently "reworked" or "refreshed" parts of a large patch. I didn't actually reduce the object-count or something. Maybe some [loadbang]s are gone (have been reduced to one), but not really worth mentioning.. Some subpatches are gone, too..
And there's everything inside.. ..some datastructures/graphics, abstractions, subpatches, sliders and stuff for the gui, ..

..The result was that the patch loaded in half the previous loadtime.
So can anyone else tell a story about this?!
I wonder what influences loadingtime the most. Any clue anyone? I'd be very interested..

In my experience it's pretty much the size of the patch and how much initialization you're doing (i.e. [loadbang]). Basically, every object when it is created has a setup routing that registers it with Pd and another one that initializes it's internal state. And then, of course, loadbanging is used to override some of the initial state with what you need for the patch. If you have samples saved in arrays, it will also take longer to load.

If you want to reduce load time, you basically do exactly what you did: eliminate unnecessary or overly complicated groups of objects and keep the patch as clean and efficient as possible.

Hey,
the thing is, it was rather optimized before already.. at least function-object-wise...
And the loadbang-reduction is really not worth mentioning... at least I don't think and hope so - it was just a handful of objects..
I more and more think the gui is the bad one here.

And I noticed something else. This Tcl/Tk (as far as I know responsible for the gui) by far must be the slowest part of pd! Before, I separated the gui to several windows. The patch took longer to load but was closing fast. Now after I repacked my gui the patch loads faster, but on closing it, it takes some time. One even can see how the ds-graphics are beeing removed "one by one"...
If someone tries this don't close pd but only the patch! Only on closing a patch there seems to be something like freeing memory "softly??"...

yeah, building up the GUI seems to have an exponential effect on load time. It's this problem that whenever a new GUI object is added to the canvas, the WHOLE canvas is redrawn.

Just use less GUI if possible. Or else, hide some of your GUI in subpatches.

I already experimented with ds-graphics..Just adding scalars does not seem to depend on the amount of scalars already there. And also just closing the "display-window" works fast enough. On opening it again, everything needs to be redrawn, that's true, but erasing the window is the step that takes unexpectedly long...
Anyways the gui takes longer than anything else to load.

The odd thing is, I didn't use less GUI but only rearranged it. And the GUI is and was always invisible on loading the patch (hidden in a subpatch).

..now is this section really the right one for these problems... ..wouldn't a FR-/Bugs-Section be better suited...

how about this... you post your patch, and let's have a look at it.