Is it possible to reduce the SMtD launchtimes? In particular, rpManager’s integration of SMtD makes rpm slow to launch, also krakatoa. But just regular smtd is slow too.
B.
The SMTD Launcher first tries to resolve the Repository location by calling deadlinecommandbg, then copies and runs the relevant scripts from the Repository every time you launch it.
So in theory it would be possible to copy those files (the functions and the UI script as well as all other components like sanity checks etc.) locally to the workstation and make them load on Max boot. This way, just running the macro (macros.run “Prime Focus” “SubmitMaxToDeadline”) would start the SMTD GUI immediately.
The current implementation makes sure that every workstation is always synced to the Repository, but if those scripts don’t change too often, it might be worth it looking into an alternative startup sequence like the above one. In fact, since the SMTD Launcher now copies the files to the local scripts folder before fileIn(), it could look locally to see if the files are there and load them instead of pulling them over the network. But you would be running a danger of executing “obsolete” versions.
I could try to prepare a quick alternative launcher for you, although I am more than confident you could script yourself one too 
With my own distribution system for plugins I have a version check. It first checks its own version number then the one on the network. It only synchronizes if the version aren’t the same. The main down side is I have to increment the version number when I change anything.
B.
I implemented a vastly faster version this morning and will let you test it.
Here is what it does:
*When you call the SMTD launcher, it first resolves the path to the network.
*It then looks for each of the necessary files on the Repository.
*It then looks for the local copy in the \Scripts or \Startup folder and compares their size and mod. date.
*If the local file exists and its date is the same as the Repository, it loads that one without copying.
*If the local file does not exist or the remote file is different, it copies over the update and loads it.
*Once this is done, a new SMTD_Startup.ms file with a line to load every component we just processed is written to the \Startup folder.
*Next time you launch Max, that Startup script is run at Max boot time and preloads all local copies of SMTD files.
*If a file fails to load within this script because it was deleted or the script itself failed to run or was missing, a global flag is set to false notifying the SMTD Launcher that it should reload all files as described above.
*Now if you call the Launcher again, it goes through the same steps above but if the global flag is true, it knows everything is preloaded and as long as the date/size check shows the local files match the Repository, NOTHING is reloaded, resulting in nearly 0 ms loading time.
The only time spent in such consecutive loads is the resolving of the Repository location which takes on our machines between 500 and 1000 ms. So instead of spending 5 or more seconds on preloading scripts, now SMTD launches typically in less than a second.
This also causes Krakatoa to find SMTD_Functions preloaded and start much faster, which is a nice side effect.
If you would update the repository, the launcher would notice the change and still copy over all new scripts. If the launcher itself got updated to load more scripts than before, it will do so AND update the startup script in the process.
I think I have covered all cases and it is a huge improvement.
The SMTD UI itself still has to collect pools and groups which takes some more seconds. I might look into caching those next so it would let you manually force an update of these if you KNOW that a pool or group has changed.
(EDIT: I just realized that with the “fast” version, once you open the UI for the first time, the SMTD Settings struct remains unchanged in consecutive loads because the SubmitToDeadline_Functions.ms is not reloaded, and thus the reloading of Pools and Groups is NOT performed. You would have to either restart Max or delete the Startup scripts or the local SubmitToDeadline_Functions.ms to force a Pools/Groups reloading, so I will add buttons for manual refresh. But it is a nice side effect of additional speed up when opening the UI more than once in a session!)
The above mechanism will only fail if something else is cleaning up the scripts and startup folders between Max sessions, but I assume this is not the case with your system.
If you feel like testing the new code, I am attaching it to this post.
Note that it will print some stats to the Listener. Try launching twice and compare the values. Then restart Max and launch again…
Deadline-SubmitMaxToDeadline_FAST.zip (2.33 KB)
Bobo, you are so awesome.
Thanks,
Ben.
Thanks for this Bobo, works a treat 
Confirmed. This enhanced script works really well