One of the things I get from the new version of Wazz, the dashboard keeping track of the automation, are timings when the automation computer starts in the morning:

So here are the events listed above:

• The Automation Computer is powered on by the museum staff… Even though I run a pretty barebone version of Debian on it, it takes some time for Linux to boot and go through the systemd init. I don’t have that timing in the events above. Measuring it with a watchclock a while ago, I believe it’s in the 10-20 seconds range.
• 9:47:25am: The “computer consist” event is sent as soon as we reach runlevel 5, the multi-user GUI. That starts a script which runs a git update on the JMRI roster, and then starts the JMRI software.
• 9:48:46am: 81 seconds later, the “conductor running” event indicates that the Conductor add-on is loaded in JMRI. These 81 seconds correspond to the loading time of JMRI, when it invokes a Jython add-on trampoline that loads the Kotlin program Conductor in the JVM. It’s all a game of classloaders and stuff, and they essentially all run in the same JVM. But still, we basically have little control on that 81 seconds timing. It’s what JMRI takes to load.
• 9:49:15am: 29 seconds later, the “conductor script” event indicates that Conductor is loading the Kotlin Script for the actual automation script. That includes Conductor opening its UI, loading the SVG map, and compiling the automation script into the Kotling Scripting Engine takes about 20 seconds just by itself.
• 9:49:15am: Less than a second later, the “toggle” events are emitted by the automation script as soon as it starts executing. At that point, the automation is “live”.

In total, it takes about 2 minutes from cold “computer off” to the automation being active.

And to be clear, that's one minute too much

The automation used to boot in 1 minute from a cold start when I was running Conductor 1.

The second stage used to be about 30 seconds faster in the past. A few years ago, I updated JMRI from version 4 to 5 and that increased the loading time. That’s also when I rewrote Conductor 1 as Conductor 2 in Kotlin, and that also increased the loading time. Using Kotlin and its Scripting Engine has a cost -- it’s after all a fairly large set of JVM libraries that are loaded dynamically into the JVM at runtime after JMRI has finished loading. So that amounted to about 30 seconds extra boot time.

Then the Kotlin Scripting Engine needs to compile the automation script at runtime and that takes an extra 20 seconds. By comparison, my old Conductor 1 ANTLR-based custom language loaded my old script in a couple seconds.

Note how I wrote above it all gets loaded into the same JVM? That matters. Conductor 2 is for now sort of stuck on an older Kotlin 1.6 version. My attempts to update to Kotlin 1.9 had failed last year, as some of the dynamically loaded libraries conflicted with something loaded earlier by JMRI or Jython. I had not figured out what exactly, and in between Kotlin is already at version 2.1 so whatever little analysis I had done is already obsolete. Most notably, I rely on the Kotlin JSR-223 support which is planned to be deprecated in Kotlin 2.3.