Achieving acceptable performance

[bitbrain]

I want to start this discussion about how to achieve optimal performance of this addon. There have been concerns raised by many how efficient this addon actually runs, especially at scale. One #168 is done, we should have a much clearer view on the overall performance as well as performance bottlenecks.

Can we not just use C++ everywhere?

I heard from many different folks that C++ usually is most performant and should be used over anything else if you want to get optimal performance. While this is generally true, it is not that simple: Godot itself is written in C++ and GDScript will under the hood still run the actual machine code that has been compiled from C++. This means, that in theory it does not really matter if you are running things in GDScript or any other language, as long the language is utilizing the C++ Bindings API. However, there are limits and certain flows may not be optimized in Godot itself - this is where writing a node in C++ makes sense if this achieves the performance benchmark goal.

So, what is the problem with C++ then? A few challenges:

• Tooling it is more complex: you need to setup SConstruct and IDE to work properly with C++
• C++ knowledge is required which is less common compared to other languages such as Javascript or Python (both very close to GDScript) - C++ simply makes the entry-level for contributors much harder - having worked on a GDExtension myself, I can tell you that there are way less people available to fix or work on things
• Workflow the workflow to make changes to the addon is much more complicated once you add C++ into the mix: you always have to recompile your GDExtension and restart Godot in order for the changes to get applied. Meanwhile, in GDScript you can change things as your game is running
• Maintainability once you decide to depend on the godot-cpp GDExtension system, you have an additional dependency to keep track on and update. Even if you are not really require new features from it, you always have to make sure that your C++ setup comforms the structure and calls methods with right names (which can change)

All in all, while C++ is more performant and can increase our frametime budget, it comes at a cost that needs to be worth it.

What is 'acceptable' performance?

This is what this discussion is about! I want to gather ideas about how we could figure out what the ideal set of "benchmarks" is that we can set up to figure out the performance of this addon. A few ideas:

• compare Beehave directly with addons from other engines (extremely biased benchmark, since mostly the performance difference can be explained by the different game engines used, and not by the addons themselves)
• setup a list of system specs (mobile, browser, desktop, OS, old CPU, new CPU) and have a set of scenes with varying complexity

Any other ideas welcome!

[warriormaster12]

One option could be to convert either just BeehaveTree node to cpp and do a benchmark comparing how long it takes for gdscript & cpp version to iterate through all nodes.

[MBoqui]

In the intention of improving performance at scale I designed my behavior tree addon to be event-driven (which I see you had interest on previously). I also tried making it into a GDExtension a while back but got stuck (IIRC something in GDExtension was broken at the time).

I'm actually interested in implementing this as it could get a lot of the AI development in Godot kinda centralized and help speed up development for everyone since there are a several plugins for this at the moment and fells like something I could help with. Since Beehave seems to be the biggest BT plugin around and it seems you might be interested, I thought of bringing that discussion here. Thanks to @warriormaster12 for pointing me here.

As for how to improve performance. Let me start by saying I haven't been following up with Beehave much since I decided to make my own plugin after not finding an event driven behavior tree. My plan when I tried to migrate my plugin to GDExtension was to convert only the core to C++ and leave all non basic nodes to the GDScript side. If thinking about eventually migrating the extension to a core module, this would not be enough, but for initial conversion, it sure seems good. I had no Idea how much migrating to C++ would improve performance. It was a plan to start benchmarking and check if it was a worthwhile endeavor.

But the biggest problem that made make my own plugin was the event-driven architecture. I did benchmark a few plugins and an initial version of mine and the time spent testing everything every single frame was really summing up in bigger trees and with a lot of agents. And this change in architecture is really hard to make later on (at least for me, I thought of forking Beehave back then but it felt like less work to make my own from scratch).

[warriormaster12]

@bitbrain seems that live-reloading has been implemented into godot godotengine/godot#80284 so restarting editor shouldn't hopefully be a requirement anymore.

[warriormaster12]

https://github.com/warriormaster12/beehave-cpp

Created a fork and I'll try to port as little as possible to gdextension

[RedstoneParadox]

Rewriting in C++ would mean that all the nodes provided by Beehave itself would be performant, but I imagine most people will write custom nodes, which will presumably be in GDScript; so whatever performance gains come from rewriting leaf, composite, and decorator nodes will likely be minimal.

Tooling it is more complex: you need to setup SConstruct and IDE to work properly with C++

Alternatively, you could use Rust (there are others but I don't think they have as much community support behind them), which is easier to set up. Of course, that comes with its caveats, like fewer people being knowledgeable of Rust, needing to rely on third-party support, and Rust not being object-oriented.

[bitbrain]

Closing this, superceded by #285