Bug Shader Graph is extremely slow since the LTS. 3000 MS instantiate of nodes.

Ben's doing testing on the shader I provided to see what we can cross of the list as suspects for the lag. I would imagine if anyone else has complex shaders they could provide or could do tests to isolate potential causes, it might get us closer to understanding exactly what the source of the problem is. I guess having about a hundred exposed parameters on a material was an unexpected use case, though to me that was just standard prototyping (hard coding comes after you perfect the values).

Apparently if you delete all the parameters, the speed increases dramatically even with the same graph complexity.

Deleting out all of the comments and headers which I insert using Shader Graph Markdown in the form of parameters had no effect. So those types of unused parameters, even when exposed, aren't the likely source.

I assume there are multiple sources of lag that accumulate over complexity, but perhaps one or two that are more extreme and which we could be helping to find rather than talking in circles.

• Is the undo lag directly proportionate to the standard action lag, or is there a specific feature that hits undo lag harder? My jump from 13 seconds to 10 minutes was massive and unexpected. Is that ratio different than what other people see?
  
• How does copy-paste lag compare (I didn't include those numbers) to undoing, creating nodes, adding connections, and breaking connections? Getting a full set of those numbers might serve as a sort of bug report. If we can get a count of the number of nodes, keywords, and parameters to go with it, we could start building a data pile for the engineers.
  
• Is it possible to make a small graph with extreme lag by isolating and repeating a bad feature?
• Does nesting with subgraphs change the result? If you take a complex laggy graph and shove it into a subgraph, which types of lag respond? Will undoing and standard actions in the main graph suddenly go faster?

Stuff like that we can be doing in small spurts. It's not exactly my specialty or my responsibility, but the whole point of the forum is to volunteer our efforts.

 

I got a report that this issue is apparently fixed in upcoming .3.8

 

Thanks for the update, Ben.

Do you perhaps have news about the findings of the engineer?

 

Unity 2021.3.28f1 here, I've only added a few keywords into an unlit node. I just want to change some floats.

30 seconds between keystrokes. How are we supposed to work like this?

 

I've had some of the same issues that @funkyCoty posted where typing numbers into a float parameter causes lag with each and every digit I type. A possible fix on that specific one would be to not apply the new value/color to the graph until a confirmation action is taken (widget loses focus, enter button, close the selector, etc.) rather than seeming to compile with each tweak. Of course that's still an imperfect solution since it reduces testing speed.

My graph is taking 8 seconds or so to enter a single number of a float or change a single property of a color. If I continue typing while it loads, it does seem to send the more completed float, but the loading starts and is unavoidable the moment I make a change. If you hit delete in the middle of typing, it queues up a separate action and must complete the load.

1<2<3<4<5<6<7<8<9, where < is deleting, the result should be 9. Before it can get there, though, it will first load to 1, then 2, then 3, and so on (not always displaying them, however), instantly beginning the compile for the next action. If you don't interrupt this process the queue appears to complete in that full form, causing a sequence of recompiles one after the next.

Deleting appears to count as a change action when the value is not already zero, incurring lag. If the value was 4, then I hit delete, I think it will auto-fill the now blank value to zero which is why it counts as a change. Once the value is zero, however, delete no longer incurs that lag. I can similarly type a repeating string of zeroes (0000) without lag because the underlying value hasn't changed. Typing example below:

0 (starting from)
<
1 (lag)
< (lag)
0
<
0
00
000
1 (lag)
11 (lag)

 

I have a very simple repro case that might be easy for the dev team to use :
- I use HDRP's template sample scene
- I have imported the FullScreen Samples (custom pass, custom post process, etc)
- I have added EdgeDetection custom pass in the scene
- now i'm trying to edit the graph
-> every node add or delete takes ages

 

Bug report: New Incident created: IN-53876

 

Just adding that we're experiencing similar issues in 2022.3.6f1.

Adding/duplicating/deleting nodes, or dis-/reconnecting anything takes an eternity, often 3+ min for a single operation.
Not to mention the time undo takes.

Granted they are pretty complex shaders, but it has gotten so bad that I'm allocating several weeks of dev time to rewriting stuff in HLSL.

It was always the intention to do this down the line, but shadergraph as a "rapid prototyping tool" is just not usable.
The fact that rewriting in HLSL at this stage is a more attractive & possibly faster solution just due to how terribly unoptimized the UI is, is very disheartening.

I really hope the engineers your engineer(s) manage to improve the the whole system substantially.
Will any of those improvements be available as a backport? Or will our project need to be updated to a new lts version?

 

Good to know
.9 is workable again but It still takes around 1 second for things to react in a medium-large shader (using subgraphs extensively)

 

That's great to hear! I will check with the relevant people if we can make the upgrade to 2022.3.10f1.

On a somewhat unrelated note: your youtube shader tutorials have been a fantastic resource, thanks a ton for providing them for free to the community!

 

Yeah I have some priceless subgraphs in my toolkit thanks to @BenCloward ..actually have them named like _____ByBenCloward.shadersubgraph ..and later realized he actually works for Unity and is active on the forum. Thanks from me as well!

 

Came here to say that there's a night and day difference in performance in .10.

Thank you for fixing this!

 

Are there any plans to bring these improvements to 2023.1?
We can't downgrade to 2022 LTS and can't risk updating to an alpha, so currently it looks like we'd be stuck with an unusable shadergraph for another few months...

 

Oh look, I am opening .10 now



my entire scene is flashing like a disco, all third party shaders broken

Also I find that recompiling a shader on .9 and .10 freezes the entire editor for 30-60 seconds
You are supposed to do stability updates, not change any fundamentals, how is this still not clear?

What are you guys doing, what the hell is going on in there??

Can we please finally work on shaders again, its been a long time, jesus christ

 

https://forum.unity.com/threads/202...-takes-forever-freezes-entire-editor.1501754/
Related thread