Pixel Crushers Forum

Hi Tony,

We recently discovered having major CPU usage spike when a dialogue system element is open in the inspector (as a quest, a location or a dialogue entry). It become difficult to edit anything for some of our developers.
We are on Unity version 2019.2 and tried 2019.4 this morning wich didn't change anything.

Do you have any idea on how to avoid or reduce this behaviour?

Hi,

That rendering overhead looks pretty crazy. It's not normal. That said, Unity's new Asset Database v2 is slower than than v1, and there was a bug in 2019.2 - 2019.3 that caused massive editor performance issues when serializing assets (e.g., writing changes to disk) that's fixed in the later versions of 2019.4 and 2020.x. If you're on the latest 2019.4, that bug shouldn't affect you. But, if you're using Asset Database v2, all asset access (not just the Dialogue System) will be slightly slower than v1 -- nothing like that profiler screenshot, though.

What version of the Dialogue System are you using? If you're not on the latest, can you back up your project and update to the latest?

Are there any errors or warnings in the Console?

How big is your dialogue database asset?

We're on version 2.2.6.
There are no errors in the console.
The dialogue database asset use 34.9 Mo.

I'll try to update if needed but I do prefer to avoid it if possible.

You could make a clone/branch of your project, update the Dialogue System in that branch, and see if it fixes the performance issue first. If you decide to update your main project to the latest version, review the release notes for any relevant changes.

Also, make sure the Dialogue Editor's Database page > Editor Settings > Fast Undo for Large Databases checkbox is ticked.

Side note: Currently the Dialogue Editor saves changes to disk every time a change is made (e.g., typing a single character into a text field). This is common practice for editor windows. However, since Asset Database v2 is significantly slower and dialogue databases tend to be large, in the next release the Dialogue Editor will provide an option to save to disk on a lower frequency such as every 10 seconds.

I justed updated on version 2.2.15 without any better performance.
As I'm using data imported from Articy:Draft, I do not need any backup of what I'm doing in Dialogue System.
I checked every other idea you shared. None of them made a difference :/

We currently are at 1/3 of the integration of the game text. Hope everything keep working later (and with the localisation).

Thanks for checking 2.2.15. I'll send you a patch in the next week or so that you can check for performance enhancements.

Since you're writing in articy, what operations are you doing in the Dialogue Editor?

When does the spike occur?

The problem is any inspector on a Dialogue System element. It's not the Dialogue System window itself.

We're writing on Articy but need to use the Dialogue System interface for the custom fields we are regularly adding.

I don't think it has to do with the real-time saving system.

Hi,

Do you mean components such as Dialogue System Trigger and Dialogue Actor?

No, I really mean the inspector view on Dialogue System : Quest, Location, Character, Database.



When the focus is on unity, and an element of the Dialogue System database is open in the inspector, the cpu spike occurs.

We can call that part of the Dialogue Editor. Although the content isn't being drawn in the Dialogue Editor window itself, the Inspector view is being driven by the Dialogue Editor in this case.

Have you ticked the Dialogue Editor's Database page > Editor Settings > Fast Undo For Large Databases checkbox?

Also make sure the Auto-Backup Frequency is set to zero or a high number such as 600 seconds.

Since you're editing in articy, I recommend defining those custom fields in articy. If you define a property in articy, the articy importer will create a corresponding custom field in your dialogue database. This may altogether prevent the need to use the Dialogue Editor in your case.