I have a TOP network that is processing a LOP graph for batching USD assets, using a custom publisher HDA via a HDA Processor TOP to do the work. Everything works fine if I only give it a small number of items to work on, but the time it takes to generate static work items gets exponentially larger as the list grows.

Given a single asset in a batch, the "Generate Static Work Items" command will take ~10 seconds to process. A list of 10 items takes about 3 minutes. 100 items will never complete generating static work items, as far as I can tell. I have waited about an hour as a test and it was still "thinking".

The TOP network is 3 nodes, using default scheduling:

1.) Range generator to get a list of the numbered assets that need to be processed (every asset in this project has an ascending ID number so it's just a range from 0-n).

2.) Python processor to handle some details like verifying that the source files exist for the asset and generating a desired output path (it checks for a previous publish and versions up if needed). It adds these new attributes to the upstream work item to be used in fields on the HDA processor.

3.) HDA processor with a custom HDA that does work similar to a component builder LOP network: takes input model file, input materials, conforms the model, assigns materials, etc. and then writes the output USD files.


When I generate static work items the range generator is instantaneous and the python processor takes a few seconds to think. Then the HDA processor, which I thought was not doing any actual work at the generation stage, will think for much, much longer. CPU & memory show minimal activity during generation.

It would be hard to share an example file of this because the publish HDAs are deeply integrated with the rest of our system -- if anyone has any guesses about the source of the slowness I could at least start stripping it down to isolate the behavior to create an example.