jsmack
You're adding nodes to the material library though. of course it has to retranslate to the stage. There's nothing you can do here except don't put a bunch of materials into a library and then edit them there. I would also not use material builders if you don't have to. principled shaders can be translated directly to usd prims, whereas material builders must create code. The code can be cached, but translation would need to happen after any change.
yes, thats what i wrote. The problem is that it happens when creating or deleting a node wherever in the materiallibrary, for example a null node inside a material builder which is not connected will also take seconds to translate. Im not whining just pointing this out a slow part of our workflow.
It doesnt matter if its a materialbuilder it is the nodes that needs to be translated. We use vray and we also use collect nodes with both vray shaders and usdpreview surface connected and it adds up to quite alot shaders quite fast which makes it slow for us.
edit1:
seems actually mtlx subnet is quite faster. But its also because its leaner and seem to only promote the parameters when they are changed from default. unfortunately mtlx is a no go for us for now
edit2:
allright, seems like there is actually 2 different things happening. 1 is vex shaders that needs to translate as jsmack said and the other one which we seem to have issue with is when its alot of non default parameters so it needs to list them all in the graph. Some renderers seem to only list shaders which have non default values. So if for example you have a mtlxsubnet with disney15 surface shader and duplicate that 30 times it will be very snappy, but if you change all the values to non default the slowdown starts to happen.