Performance problems

[diccon]

I'm hoping to use Dialogue System for in flight co-pilot speech for a flying game, and getting frame rate spikes whenever I call StartConversation. I've attached a screenshot of the profiler so you can see what I mean (I added the Conversation.Start profile markers around DialogueSystemController::StartConversation).

I'm going to dig into this myself but can you make some suggestions about how I can make this go faster? Caching and reusing ConversationController, ConversationModel, and ConversationView look like easy wins, but what is making 8000 allocations?

As you can see from the screenshot the conversation is just a simple line of text so there is no reason for it to impact the game like this.. Any help is much appreciated.

Profile:


Screenshot:

[Tony Li]

Hi,

On the Dialogue Manager, make sure you've ticked Preload Resources and Warm Up Conversation Controller.

The majority of those allocations are probably related to Unity UI. The options above should reduce or eliminate them.

Depending on your conversation, the next largest may be evaluating conditions on nodes. If you have a large number of initial nodes (i.e., linked from <START>) all with conditions, those conditions need to be parsed and evaluated in Lua. Reduce the number of nodes to evaluate by using group nodes to filter out groups of initial nodes.

If you know the conversation will always have something to say -- that is, there won't be a case where all initial nodes' Conditions are false -- untick the Dialogue System Trigger's Skip If No Valid Entries. This prevents the Dialogue System Trigger from doing double computation of the initial nodes' Conditions.

[diccon]

Thanks for getting back so quickly as always, the spike is reduced by about half but its still bad. Actually your second hypothesis the lua interpreter seems to be the main culprit, I did a deep profile which shows the bulk of the allocations are happening there. I've attached another screen to show the conversation that is being evaluated, its currently very simple as I build out the system, my code pushes an integer variable and that determines which node to play, currently there are only two nodes to evaluate. Its suprising to me that such a small set of conditions would result in so much processing, I guess I will have to rethink my approach, maybe its not possible to have conversations with any conditions during the flight sequences.

Profile with warm up controller:


Deep profile:


Conversation:

[Tony Li]

If that 0.029-second delay is too long, you could replace those variable comparisons with a custom Lua function such as:

Code: Select all

IsCurrentFlightEvent(3)

that involves less parsing and evaluation of arrays.

Or, to completely bypass it in the worst case, here are two options:

1. Don't use Dialogue System Trigger. In the script that sets flight_event_current_event, you could instead use DialogueManager.BarkString() to bark a different string for each value. If you don't want to specify the string in the script/inspector (to separate code from data and/or handle localization), you can use a StringField, and assign an element in a Text Table asset to it.

2. Or separate your flight conversation into separate conversations, perhaps based on the current event number (Test Flight 1, Test Flight 2, etc). Don't use Dialogue System Trigger. In your script, call DialogueManager.StartConversation("Test Flight " + currentEventNumber).

[diccon]

Thanks again, I'm not using Dialogue System Trigger, I have my own manager that sets the variables and calls StartConversation directly. I'll try making each event its own conversation, and I think I'll also need the variable comparison function to handle things like fuel and health values.

[Tony Li]

Sounds good!

[T j]

the image that OP provide it has malware

[Tony Li]

Norton seems to think it's safe, although Malwarebytes thinks it may be suspect (spam perhaps). Anyway, always use care when following any links anywhere.

[diccon]

I'll use a different imagehost next time (these are on imgbb.com).

Update on this problem - I've managed to achieve a reasonable performance by making a butchered version of the Bark UI that removes the features I'm not using and rewriting FormattedText to use static StringBuilders so it doesn't allocate, this brings the execution time down to 4-8ms ms on my 5 year old dev PC which is acceptable for now.

One thing puzzles me though is that the first run of any Conversation runs a lot slower than subsequent times, the first time is in the range of 4-8ms but the next time will be 1-2ms (which is great!). I wrote a similar function to WarmUpConversation for my custom which shows the custom BarkUI for an instant when the scene opens which helped, but even with this there is a big performance difference between the first and subsequent runs which puzzles me.

I have other ideas such as pregenerating the ConversationModels or lua Chunks but dialogue is no longer the worst performance spike so its enough for now.

[Tony Li]

Version 2.3 will have an improved warmup routine that should bring the first time down to 1-2ms also. I'm just waiting on testing confirmation, and then I'll release it as a patch. The biggest performance hog when starting the first time is Unity UI re-layout, especially if you're using TextMesh Pro. The new warmup routine should take care of it, though.

I also have a task scheduled for version 2.3 to cache ConversationModel, ConversationController, and ConversationView, but this may get pushed since, as you mentioned, it's not the main culprit, and it won't help in projects that play multiple simultaneous conversations (which is the reason they're not cached in the first place).