GC.Alloc Issue with Nested BehaviorTreeReference (External Behaviors)

H

HYEONWOO NAM

New member
Dear Opsive Team,

I am writing to you today regarding a performance issue we've encountered while developing our project using your excellent Behavior Designer asset. We have identified garbage allocations (GC.Alloc) at runtime, and after profiling, we've traced the source back to the Behavior Designer.

Specifically, the issue occurs when we use a BehaviorTreeReference task within another BehaviorTreeReference (a nested external behavior setup). Despite implementing your recommended pooling system, we've found that the initial call to EnableBehavior on the parent tree triggers BehaviorManager.LoadBehavior. This process, in turn, calls ExternalBehavior.CheckForSerialization and its deserialization methods, leading to substantial GC allocations.

We noticed this exact issue has been discussed in your forum previously, as seen in the following thread
https://www.opsive.com/forum/index.php?threads/performance-issue-when-loading-behaviour-tree.1104/

Given that this is a critical performance bottleneck for our project, we would like to inquire if there has been any progress on this matter or if you could provide us with further guidance on how to mitigate these allocations. Is there a recommended best practice for using nested external behaviors that we might be missing, or are there any known workarounds?

Your assistance on this matter would be greatly appreciated. Thank you in advanced for your time and support.

Best regards,
HYEONWOO NAM
NEOWIZ
 
There hasn't been any more progress on this, and the suggestion given by @xjjon with giving an already deserialized external tree is a good one. Unfortunately the original version of Behavior Designer is in maintenance mode and I am only fixing bugs.
 
Thank you for your quick response.

I have a few follow-up questions regarding your reply.
  1. Is Behavior Designer Pro currently under development?
  2. If so, will the Pro version resolve the GC allocation issue that occurs with nested BehaviorTreeReferences?
  3. How straightforward is the upgrade process from the current version to the Pro version?
  4. Is it mandatory to use DOTS (Data-Oriented Technology Stack) when using the Pro version, or can it be used with the standard Unity GameObject/Component system?
We appreciate your continued support and look forward to hearing from you.
 
1. Yes
2. Interesting timing as this is actually something that I was working on earlier this week. As of the next version you can set a Pooled property on the subtree (formally external behavior) and that subtree will not be copied when it is used within a Behavior Tree Reference. This version will likely be released on Monday and I'll update the documentation at https://opsive.com/support/documentation/behavior-designer-pro/subtrees/
3. There is no migration and you will need to recreate your tree, but it is fairly easy to convert your existing tasks: https://opsive.com/support/documentation/behavior-designer-pro/getting-started/task-migration/
4. You can use GameObjects.
 
You must log in or register to reply here.
Back
Top