Rosanswers logo

When running Movit on my desktop, RViz cannot show smoothly arm trajectories. Well, it looks cool at the beginning, but after 2 or 3 extra plannings/executions, CPU load reaches 100% and arm trajectories become jumpy.

The point is that my laptop, with a less powerful CPU (same RAM) does a much better job, with RViz taking ~80% of CPU, because in a thread-by-thread basis, is much faster:

  • Desktop: AMD FX Series FX-8350 4.0Ghz 8 cores
  • Laptop: Intel i7-4600U 3.00 GHz dualcore

So... weird as it can sound, I would love a multi-threaded RViz, or recompile it better fitted for my CPU.

Any idea of what can I do? (I tried overclocking but always make the PC unstable)

Hope this gets useful for ROS users thinking to buy a new PC: carefully check per-thread performance!!!


I made some progresses; compiling RViz for my platform improves things, so now, if I disconnect the 3D sensor, RViz never reaches 100% CPU and so the arm moves smoothly:

set(PLATFORM_FAMILY "amd" CACHE STRING "Platform family, usually referring to intel/arm etc.")
set(PLATFORM_NAME "native" CACHE STRING "Platform name, usually referring to the cpu architecture.")
set(PLATFORM_CXX_FLAGS "-march=native" CACHE STRING "Compile flags specific to this platform.")
set(CMAKE_BUILD_TYPE Release CACHE STRING "Build mode type.")

However, performance still degrades when RViz shows the octomap (but takes longer). Someone knows any additional compilation tweak to try? Btw, how can I override the predefined compiler flags? It uses -O2, while I want to try -Os instead (I saw in a benchmark assuring it's better for my CPU)

Another solution could be to simplify the arm. Yes, I use the tiny turtlebot arm, but the URDF is surprisingly complex, as it adds a link for every frame element, totaling 25 links! (with 23 meshes). Makes this any sense? Or it will be a waste of time?


Originally posted by jorge on ROS Answers with karma: 2284 on 2014-07-27

Post score: 1

Original comments

Comment by ahendrix on 2014-07-27:
Are you sure this is related to CPU performance, and not due to poor graphic performance?

Comment by gvdhoorn on 2014-07-28:
I'm inclined to say the same: on my -- even slower -- machine (2.8Ghz, c2d) -- I can run RViz and MoveIt for hours on end, without it eating up my entire CPU. Could you add some more info on the rest of your hardware?

Comment by jorge on 2014-07-28:
Well, I'm pretty sure it's not the graphic card because I have a one that should be more than enough for RViz (AMD HD 7770), while I have none in the laptop. And even like this, the laptop works better. Also, I changed to proprietary AMD drivers without noticing any improve on RViz

Comment by kmhallen on 2014-07-28:
Any parameter starting with 'D' is passed to cmake. catkin_make -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=-Os
catkin_make -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-Os -march=native"

Comment by jorge on 2014-07-29:
Yes, I have no problem passing arguments to gcc. But I don't know how to remove the default ones, e.g. -O2.

Comment by Daniel Stonier on 2014-07-29:
When you build in ros, the -O's will be applied by cmake according to the CMAKE_BUILD_TYPE setting.

Comment by Daniel Stonier on 2014-07-29:
Run top on the rviz process, use H (threads) and f (fields, select the last used cpu). Are you seeing all the computation in one thread? Mine is, but I'm not testing on anything significant. Being a qt program, I wonder if all the hard yakka is getting done in the main thread.

Comment by Daniel Stonier on 2014-07-29:
Such a large program with alot going on could farm out some jobs to threads or hang widgets on the main one from external threads, but that starts to require some thinking/planning.

Comment by Daniel Stonier on 2014-07-29:
Would starting two instances of rviz with different things showing in each help you multi-core it?

Comment by jorge on 2014-07-29:
One single big glutton thread takes all CPU. As far as I can say, the thread gets 100% of CPU because it process the monitored_planning_scene topic from moveit, that contains really a lot of information. But... I'm new on moveit, so this is just my guess.

Comment by jorge on 2014-07-30:
My college in the office complain that he set CMAKE_BUILD_TYPE as Debug and still have the -O2 optimization option. There's no way to change pre-set options for a compilation type?

Comment by Daniel Stonier on 2014-07-31:
Those -O2 settings are defined as preset configurations by cmake modules that define the compiler you are using (I'm pretty sure). You can override these with: http://www.cmake.org/cmake/help/v2.8.10/cmake.html#variable:CMAKE_USER_MAKE_RULES_OVERRIDE.

Comment by Daniel Stonier on 2014-07-31:
Basically you create a file with something like: set(CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT} ${MY_FLAGS_INIT}") and set CMAKE_USER_MAKE_RULES_OVERRIDE with the filename in your cmake pre-cache.


1 Answer 1


Rosanswers logo

After edit: you never mentioned that you were doing things with Octomaps, which is why I assumed (and I think @ahendrix as well) that the performance bottleneck was within any of the subsystems RViz uses, and the performance problems were always there, even when just doing simple path planning with MoveIt.

If performance degrades over time, perhaps you've ran into a memory leak issue. RViz has had some of those in the past (see issues/556 and issues/695 fi). You could use any of the standard tools to catch those.

To get a feeling for which nodes / processes are taking up all the CPU time, try to run rqt_top or just normal top and see what is going on.

Edit: just realised that it could very well be something else (ie: not RViz) that is your performance bottleneck.

Originally posted by gvdhoorn with karma: 86574 on 2014-07-29

This answer was ACCEPTED on the original site

Post score: 0

Original comments

Comment by ahendrix on 2014-07-29:
If this really is a memory leak, it's entirely possible that rviz is bottlenecking on memory speed (and not CPU speed) on you desktop vs laptop.

Comment by gvdhoorn on 2014-07-29:
If something is constantly malloc-ing/new-ing, then yes, I agree. I can see that becoming a problem with pointclouds/octomap usage.

Comment by jorge on 2014-07-29:
OK, my mistake: I shouldn't have mentioned the octomap, as this can blurry the discussion. The performance degradation happens without visualizing octomaps. It just gets worse if I show them, but this means that RViz gets more loaded showing them, not that the CPU struggles creating them.

Comment by jorge on 2014-07-29:
I'm pretty sure on this because I have monitored the CPU usage of all processes, and the only making heavy use of the CPU is RViz. That said, I have also observed that RViz keeps taking more and more memory after executing a plan, so looks like it has important memory leaks. I will try with valgrind


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.