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
<[email protected]> 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/e3e0d9738c66ebf2f9227b34e16331647ab149a5
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
