QML is very slow compared to headless mode

[hannesdelbeke]

When running (openmaya) checks on a few cubes in maya.
it takes 10 seconds in QML, but is instant in headless mode

headless. <1 sec

import pyblish.util
pyblish.util.publish()

QML takes about 20 sec !

pyblish lite also has this issue

[BigRoy]

Could you try reducing the Pyblish delay? I know in Pyblish Lite that can help a ton but out of the top of my head I am not sure whether it's also a thing in Pyblish QML. Did a quick search over the code. Pyblish QML does not have this env var.

import os
os.environ["PYBLISH_DELAY"] = "0.1" 

You can lower it even further with the code triggering faster but at the cost of the Pyblish UI appearing much less responsive.

---

In Pyblish QML you could have a look at whether there's any usage of util.schedule that could have a shorter time. For testing even could add the PYBLISH_DELAY inside the util.schedule as a multiplier for time similar to how Pyblish Lite implements that env var. See if QML breaks, because there are likely reasons that scheduling was introduced but the default numbers might be on the very safe side to optimize the most fluent UI experience but sometimes you just want faster publishing instead.

Since there has been a commit to increase a specific schedule time here that was likely to resolve an issue so I assume you can't reduce all usages without errors.

There is also util.wait which has a set delay. Not sure what happens if you would reduce that. 🤣

[mottosso]

Yes, this is intentional. The UI is meant to communicate what happens, rather than finish as soon as possible. If the user isn't interested in what happens, that's where the scripting equivalent comes in handy.

You could lower these delays; as Roy mentioned they are in there to keep the UI responsive and to make it more clear what happens and in what order. But the exact quantities are subjective and tuned for the most general case.

[hannesdelbeke]

oh amazing. That's exactly what i'm after.

I've used intentional delays in the past, but prefer
"if it's less then 0.5 sec add delay else do nothing!"

[hannesdelbeke]

Thanks for the advice

when setting

os.environ["PYBLISH_DELAY"] = "0" 

it's a lot better but not fast enough yet with multiple checks and instances.
it still takes 5 seconds on a scene with a few cubes.

any clues where i should start looking to remove any more delays?

the util.wait appears to be startup related. so changing that doesn't do much.
i'm mainly interested in making it faster after it is booted.
i'll try my hand at profiling see if that shows anything

[hannesdelbeke]

most time appears to be spend on QT events. (see bottom snippet)

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
...
49788    0.103    0.000    0.182    0.000 \pyblish_qml\models.py:242(data)
78    0.008    0.000    0.514    0.007 pyblish_qml\models.py:475(update_with_result)
468    0.007    0.000    0.621    0.001 pyblish_qml\control.py:1072(update_instance)
78    0.003    0.000    0.651    0.008 pyblish_qml\control.py:1053(update_context)
79    0.001    0.000    0.744    0.009 pyblish_qml\control.py:1042(on_next)
4104    0.012    0.000    1.011    0.000 pyblish_qml\models.py:233(_dataChanged)
4104    0.011    0.000    1.232    0.000 pyblish_qml\models.py:122(set_data)
12407/8205    0.910    0.000    1.323    0.000 {method 'emit' of 'PySide2.QtCore.SignalInstance' objects}
264    5.726    0.022    5.783    0.022 {function Window.event at 0x000002257BACCC10}
264    0.019    0.000    5.802    0.022 pyblish_qml\app.py:34(event)
...

[hannesdelbeke]

actually tried to set delay to high and no difference in time.
os.environ["PYBLISH_DELAY"] = "2000" 

update: checked code and only lite is using this env var.

[hannesdelbeke]

tried lite, it's running a lot faster than QML which is nice.
when setting
os.environ["PYBLISH_DELAY"] = "0" 
it processes instantly, exactly what i want.

i'll swap to lite for now . a shame since QML looks nicer

QML takes about 5 sec
lite 0 seconds

yes it's less responive but it's better than having to wait 2 minutes on big scenes.

[BigRoy]

@hannesdelbeke Be aware that at delay 0 in Lite you'll likely run into the case that if a single plug-in is actually slow to process that during that processing the UI might lag and still show the previous plug-in as if it was in the running state. This might make users wrongly think it's the other plug-in is still processing.

[hannesdelbeke]

good to know
it sounds like a UX bug in lite.

don't think it matters in my scenario, since my main objectives are:

• have all plugins run fast
• user only cares about end results, and uses GUI to visualise those results.

the speed of how long a single plug takes is a TD thing, since users cant change anything about it.