major collision checking performance regression

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

major collision checking performance regression

Michael Koval
Hi Rosen,

We recently simplified HERB's geometry and were surprised by how little it decreased our planning times. As as sanity check, I re-ran a benchmark script (attached) that you sent out to openrave-users back in 2009. At that time, you reported that 1000 collision checks took 0.009739 s not in collision and 0.016202 s in collision.

In a recent build of OpenRAVE 0.9 I got timings of 0.018934 s not in collision and 0.111590 s in collision, which is nearly an order of magnitude slower than your results. Note that the actual slowdown is likely significantly worse: this computer (3.2 GHz Intel Xeon E5-1650) is almost certainly faster than the one used to run the benchmark in 2009.

We find this result startling. Do you have any idea what could have caused this amount of slowdown?

Thanks,
-Michael (and the Personal Robotics Lab)

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users

collisiontiming.py (594 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: major collision checking performance regression

Rosen Diankov
Administrator
hmm.... the following reasons come to mind

1. boost python switching
2. mutex locking (environment mutex and ode mutex)
3. ODE (different compilation flags, different algorithms)
4. GCC
5. Python?
6. OS (i'm guessing you are using a later version of ubuntu, which most likely is slower)

the only way for you to figure out which is to start timing individual parts that are being used in CheckCollision. I would write the test in C++.

for example, by setting collision checker to None

env.SetCollisionChecker(None)

time timings will show the system overhead of making the actual calls.

hope this helps,





2014-07-25 6:41 GMT+09:00 Michael Koval <[hidden email]>:
Hi Rosen,

We recently simplified HERB's geometry and were surprised by how little it decreased our planning times. As as sanity check, I re-ran a benchmark script (attached) that you sent out to openrave-users back in 2009. At that time, you reported that 1000 collision checks took 0.009739 s not in collision and 0.016202 s in collision.

In a recent build of OpenRAVE 0.9 I got timings of 0.018934 s not in collision and 0.111590 s in collision, which is nearly an order of magnitude slower than your results. Note that the actual slowdown is likely significantly worse: this computer (3.2 GHz Intel Xeon E5-1650) is almost certainly faster than the one used to run the benchmark in 2009.

We find this result startling. Do you have any idea what could have caused this amount of slowdown?

Thanks,
-Michael (and the Personal Robotics Lab)

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Loading...