Resolve Publish Extremely Slow

General
1

Hey everyone, we’ve noticed while publishing editorial plates and shots in Resolve that sometimes the publish takes an abnormally long time to complete. After running some profiling tools, it appears, oddly enough, that the slowdown is coming from the refresh of the publish window reports page at the very end of the publish, after all the processing plugins have already run.

The result is that sometimes the bulk of the publish completes in a few minutes, and then the UI is stuck frozen preparing the reports screen for up to 20 minutes or more. Has anyone else experienced this kind of hanging/slowness with the resolve integration ?

2

Not noticed this at the end of the publish but have noticed a big hang on larger publishes when validation finishes, but no where near 20 minutes, more like 2 or 3 and this is in Maya + Blender

3

Not noticed this at the end of the publish but have noticed a big hang on larger publishes when validation finishes, but no where near 20 minutes, more like 2 or 3 and this is in Maya + Blender

I’ve had these in the past for publishes where the logs turned out to be MASSIVE. I tended to avoid all the debug logging of full instance data which we had here and there and removing those would make it already tremendously faster in my experience.

Is that the case for you too?

The result is that sometimes the bulk of the publish completes in a few minutes, and then the UI is stuck frozen preparing the reports screen for up to 20 minutes or more. Has anyone else experienced this kind of hanging/slowness with the resolve integration ?

Not with Resolve in particular, but in Maya - yes. If lots and lots of data was logged the report generation took relatively excessively long. But would be great to know for sure that’s your case as well before we start investigating.

4

Interesting, was the user on Details tab, or just Report?

I can imagine that Details tab could cause that but not for Report, would be nice if you could share the report json (I expect it contains sensitive information?).

I wonder if the slowdown is because of UI or because the report is being created before UI shows it.

5

The user is on the Reports tab. And the reports themselves don’t look to be excessively long, they are pretty comparable to logs we have in maya that publish quickly.

Just by throwing a bunch of prints around, I found that the blocking was occuring on the _on_publish_stop slot in the report page. And then running the profiling tools, it seems that the update of the page, which includes creating many widgets, is where the slowdown happens. This latest test publish of 4 shots took about 25 minutes to complete:

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000 1602.618 1602.618 C:\Users\veena.vignale\work\ayon\dev\resolve_latency\core\client\ayon_core\tools\publisher\widgets\report_page.py:1997(_update_state)
        1    0.001    0.001 1602.616 1602.616 C:\Users\veena.vignale\work\ayon\dev\resolve_latency\core\client\ayon_core\tools\publisher\widgets\report_page.py:1861(update_data)
        1    0.000    0.000 1591.187 1591.187 C:\Users\veena.vignale\work\ayon\dev\resolve_latency\core\client\ayon_core\tools\publisher\widgets\report_page.py:1494(update_instances)
        1    0.001    0.001 1591.187 1591.187 C:\Users\veena.vignale\work\ayon\dev\resolve_latency\core\client\ayon_core\tools\publisher\widgets\report_page.py:1446(_update_instances)
       10    0.032    0.003  955.763   95.576 C:\Users\veena.vignale\work\ayon\dev\resolve_latency\core\client\ayon_core\tools\publisher\widgets\report_page.py:1345(__init__)
       10    1.692    0.169  955.730   95.573 C:\Users\veena.vignale\work\ayon\dev\resolve_latency\core\client\ayon_core\tools\publisher\widgets\report_page.py:1265(__init__)
6

That’s very good sumup indeed. So we’re sure it is most probably only frontend issue, so the question is how to optimize that. I guess blocking update of the parent widget untill all widgets are created might help a lot.

7

Could the widgets be created lazily, so they only generate when the user goes into the details panel - which majority of users won’t do?

8

I did find at least one optimization to reduce the number of calls to setVisible() on widgets in the reports view (which were oddly expensive), but we’re still waiting on feedback from user testing to see if it produces substantial time savings.

1 Like