Hi,
we have an issue where populating the context menu in the webui with available applications for the entity takes a long time (up to 5 mins) the first time, after that its cached and therefore faster. That initial wait time isn’t helping with adoption of sg into our projects.
As far as I can tell this happens because in tk-framework-desktopserver, there is a get_commands.py in which the commands ultimately get found. It gets called through a subprocess.Popen (through a few more hoops) from api_v2.py.
I understand this is done because an engine (tk-shotgun) needs to be bootstrapped, and that cant be done in the caller because the caller already has a different engine running (tk-desktop).
The issue here is that for each application configured in the different yamls in the config (asset.yml, asset_step.yml, …) this subprocess is run, and as soon as the context changes it needs to be run as well (in the case where the context menu is used on another entity of a different type. These many MANY bootstraps are what causes the slowness.
I dug through the code to find where the commands to start the applications are registered on the engine when tk-shotgun gets bootstrappped, but the code base is so heavily abstracted that I stopped at the nth level.
Boils down to this:
is there another way to get at the startup commands, which is faster than bootstrapping tk-shotgrid engine and use the .commands property? Also there is overhead in starting a python subprocess so often.
I had some ideas to make it faster, but figured i’d ask here before.
- A mock engine which only resolves the commands, so bootstapping would be faster.
- Create a standalone permanently running application which bootstraps tk-shotgun once and can switch context. From api_v2.py I could then query that application with a new context.
- Pre-cache all startup commands for all entities, maybe when Desktop is started?
Stefan Braun
TD at 3ds