Home | Tutorials | Wiki | Issues
Ask Your Question

Unexplainable slowdown over time

asked 2019-01-06 14:35:26 -0600

david_d gravatar image

updated 2019-01-06 14:38:37 -0600

I have a simple world plugin that creates several objects, waits a few seconds, deletes the old objects, and repeats this process several times.

For reasons I cannot identify, over the course of these iterations, the speed of the simulation slows down (the real time factor gets worse). Using the unix time utility to test, I've found the simulation starts off doing ~0.8 iterations per second, but after ~15 minutes of the simulation running, it gets down to 0.15 iterations per second.

  • As far as I can tell, nothing persists or accumulates between iterations, so I don't think it's the simulator getting cluttered with more and more objects.
  • According to htop, I can't see the resource usage of Gazebo increasing, so I don't think it's a memory leak, but I could be wrong.
  • The only thing I could think of is that one of the models created each iteration has a plugin, and the plugin may be slowing things down? However, as far as I can tell, there's only one of these plugins printing anything at any one time, as expected, so I assume they're getting suitably destructed between iterations.

Does anyone have any guesses as to the cause of this? My hacky solution is to just restart gazebo after 30 iterations, but this is hardly the best solution. You can see the relevant source code here. Thank you for your help.

edit retag flag offensive close merge delete


Any reason why you're using `Model::Fini` instead of `World::RemoveModel`?

azeey gravatar imageazeey ( 2019-01-07 17:55:33 -0600 )edit

No reason in particular.

david_d gravatar imagedavid_d ( 2019-01-07 18:28:32 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-01-08 09:45:13 -0600

azeey gravatar image

I think the preferred way of deleting a model is by sending an entity_delete request. I believe this avoids various race conditions and makes sure every subcomponent of Gazebo is notified of the deletion. Here's another explanation.

And here's a snippet of code as used in gz.

msgs::Request *msg = msgs::CreateRequest("entity_delete", modelName);
transport::PublisherPtr pub = node->Advertise<msgs::Request>("~/request");
pub->Publish(*msg, true);
delete msg;
edit flag offensive delete link more


Ah, it's a good suggestion, I wasn't aware that method existed. Unfortunately, I can't test if that fixes the slowdown, because now it crashes on iteration 3, every single time. I have no idea why, no error messages are listed, except for a single time, where this error appeared: (__pthread_mutex_lock_full: Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust' failed.) Very strange...

david_d gravatar imagedavid_d ( 2019-01-09 18:24:50 -0600 )edit
Login/Signup to Answer

Question Tools

1 follower


Asked: 2019-01-06 14:35:26 -0600

Seen: 35 times

Last updated: Jan 08