Hi there,
We’re finding that when we have more than a few pipeline configs active that the time taken for SG to setup the menus on the Website and in SG Create becomes painfully slow.
I’ve raised this in a support ticket before, but thought I’d see what the community has to say.
My solution was to suggest that pipeline configs have a checkbox to disable access in particular environments; eg sg_create_disabled and the sg_web_disabled.
SG support suggested disabling the pipeline configs by either user restriction or plugin field, but that doesn’t really work for us as we still need to be able to use the pipeline config via SG Desktop for development work.
I appreciate that this is a bit of an edge case for developers only as normal users would typically only have one pipeline config available to them in any particular project.
I find the integrations menu load to be slow even for users with access to just one pipeline configuration. It would be great for these to load quickly for users, especially as we try to roll out these features with artists that are not used to them.
We also find it slow in general to generate the toolkit menus, even with access to just one config. If it was slow only after an update was rolled out, I could live with that, but sadly that’s not the case for us… Any way to cache them and then just update the list whenever needed?
Hi all - sorry to hear you’re experiencing this. We’ve heard it from others too. I’m going to run this by the team so that, a) they have the feedback that things are slow, and b) we can report back to you all if there are any workarounds or known issues.
(This applies to SG Desktop’s browser integration, I’m not currently sure if this still applies to the Create.)
This may not be the case in your situation, however I thought its worth mentioning.
The actions are cached, per user, per project, per entity type. If it is the first time the actions are being cached for any of these elements, then it will initially be slower. Subsequent loads should be faster.
If a config is detected to have changed then it will trigger a re cache, though this is done in the background and the result will apply to the next page load, it will serve up the old cache for the current page.
However if you have multiple configs on a project and one of those configs throws an error whilst it’s generating the actions, it will not store the cache for any of the configs and will mean that the menu’s have to be generated from scratch time.
I don’t think Create is caching the menu unfortunately and it is super super slow to the point the menu is unusable, at least for me, Desktop and Web are kind of slow but they do cache I think.