Interesting... (sorry, my mailer seems to insist that my replies show up ahead of all quoted text...)
In Pd's case there are two processes (Tcl front end and Pd itself) which ideally should start up in parallel, but which my latest startup-order change seems to have made happen in sequence instead. But I can't make any sense of the variations in startup time I'm seeing. Anyway, it's now about 1-1/2 second on my m2 machine so it's not fatal, just annoying.
cheers
Miller
On 5/20/24 10:15 AM, Kjetil Matheussen wrote:
On Mon, 20 May 2024 at 09:48, Miller Puckette mpuckette@cloud.ucsd.edu wrote:
To Pd dev - I've gone ahead and pushed 0.55-0test3 to github in hopes it will work OK. I think I've fixed the startup order problems, but two problems remain... 1. startup is noticeably slower than 0.54 on MacOS. I've been trying to track this down, and pushed a branch to git that should have improved the startup time but I don't see any improvement on my Mac. OTOH, when I compile Pd locally it starts up noticeably faster than either 'master' or 'startup-order' branches compiled in the online CI system. I'm baffled but will keep trying to figure this out.I had a really strange slow startup time regression on mac for Radium as well. It seemed to be caused by slow performance when allocating memory. guess the problem is in macos itself. My workaround was simply to allocate in parallel (i.e spawning lots of threads) instead of allocating in sequence. The following commit reduced startup time on mac with around 10 seconds on an m3 mac! (on windows and mac this code took no time at all, because it’s not really doing much)
https://github.com/kmatheussen/radium/commit/e3e0d9738c66ebf2f9227b34e163316...