Any idea on Speeding Up BT Initialization

First of all, I hope this is the right place to ask such a question (in comparison to issue page on github). If not let me know to switch over there.

I have a really big BT that has lots of subtrees . Each subtree has aslo more subtrees and finally some leaf nodes that call services or subscribing to topics or publishing topics to ROS. All the leaf nodes normally check the existence of the topics, register to them or other kinds of preparations in the Node Constructor or in initialization function (as visitor). These process, before starting the first tick, takes about 4 minutes on my machine.
I’m thinking about a parallelization idea that make all of these preparations in parallel. And then the BT can run the ticking process normal in a sequential way.
First question is that is there already any thing similar inside the code base that I can use or start from? And if not where could be the best location in process follow inside the code for implementing such a thing.



yes, this is a good place to ask these questions.
I am very curious to know more about your use case and see if there is a fix.

Creating/initializing Nodes in parallel is technically possible, but complicated.
Furthermore, I think we are just trying to solve the symptom of an underlying architectural problem, instead of the problem itself.

Would you like to give me more information about:

  • the number of nodes, roughly
  • do you duplicate a lot the nodes with the same ROS Action/service/topic.
  • Would you be able to provide statistics about where the time is spent?

I would like to help. You may contact me also in private if you want


Hi Davide,
Many thanks for your responses and the time you spend on BT. I really appreciate it.

Actually in my use case, I’m trying to completely design my middle level and high level application logic in BTs. Some years ago when I started using BT, I tried to write some BT nodes for calling Services, actions and after a while I noticed, for every new system that I want to integrate in (with different services, actions,topics ), we should write new BT nodes(or plugins as it is done in NAV2).

So recently I have also developed (that is still in development) some general BT plugins on top of your BT.ROS that makes it easy to call any unseen service, publishing /subscribing new topics, or even making new ROS messages or extracting info from ROS messages inside BT xml with the help of on the fly generated ports(using ofcouse your beloved ros_babble_fish project made by StefanFabian). These approach increases the number of nodes in XML but give the flexibility of editing Business Logic as configs inside XML files (and later in UI :wink: )

Now about the questions:

6755 is the last generated UID in my three. I can assume half of these number could be my leaf nodes.

If I understand your question correctly, yes, I have maybe maximum 30 different BT nodes that are used (instantiated) with different service/action/topic names.

for this I should dig in more but my first measurement shows 67 seconds for this three with 6755 different nodes, and as I said this is the time spent in createTreeFromFile() , before starting the first tick.

I have already sent an email to you (from Mahmoud@Farshbaf.Net). I would be my pleasure to be in contact with you and maybe contribute to this awesome and powerful tool.


The idea of creating versatile and rusable nodes with ros_babble_fish is great.

I think that if we could benchmark where time is spent, we may find a good architectural solution.
Creating 6755 objects is fast, so it much be some specific operations that is taking too much, we need to know which one.

I am a big fun of using perf + Hotspot to do this kind of profiling:

You are right. As I also noticed before, the object creation from BT side is fast.

But if the nodes (or just one node) are doing sth in this object creation phase (for example waiting for a service/topic to be available) then the whole tree creation process will be paused until this is done.

I have some ideas that I will try to summarize and then we can think about how to go forward with a use case+ profiling.