Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate performance issues #124

Open
gadomski opened this issue Jun 26, 2017 · 6 comments
Open

Investigate performance issues #124

gadomski opened this issue Jun 26, 2017 · 6 comments

Comments

@gadomski
Copy link
Owner

Several users have reported that this C++ implementation is slower than the Matlab implementation.

@RolandZhu
Copy link

I agree, any idea about how this happens? My current project registers about 200 points in real time. Even enable fgt will slow down the process, and using Matlab(10ms) is faster than using C++(15ms), may I ask for any comment on that? Thanks.

@gadomski
Copy link
Owner Author

@RolandZhu no comment other than that I'm looking into it :-).

@marcopus
Copy link
Contributor

marcopus commented Aug 4, 2017

I also have this problem. I gave it a try with cpd to morph 3D point clouds of bones for a human modeling application. These point clouds have in the order of 10k vertices and I wanted a streamlined way to morph sources to targets point cluods on-the-fly, by simply running an executable from the command line, instead of computing the registration off-line with MATLAB.

It turns out that not only MATLAB implementation is way faster (~5 minutes for a rigid+nonrigid registration using fgt lowrank) but I don't even get the nonrigid registration results within a reasonable time with the C++ program I just compiled. I've got the process running for 2 hours now, and so far it did only 16 iterations with the fgt direct-tree method, while MATLAB took ~350 iterations to converge. So it's just taking forever. ifgt and switched methds do not even pass the first iteration, strangely enough.

Parallelization might speed up the process a bit I think, but I wasn't successfull to build cpd with openmp-enabled fgt (which must be built as shared library), and cpd searches for static libraries of fgt apparently, or I was doing something wrong.

I would be glad to hear about any development on this.

@aanwark
Copy link

aanwark commented Nov 10, 2017

@marcopus I have noticed the same issue, with my tests the Matlab implementation is much faster than its C++ counterpart. I have one confusion though; is there a flag that needs to be set, if the library is needed to be compiled with fgt support? I compiled and installed fgt before and used a flag -WITH_FGT while doing cmake .. on this code. Is this approach right?

@gadomski
Copy link
Owner Author

No updates on performance as of yet, other than to make sure you're compiling in release mode (CMAKE_BUILD_TYPE=Release).

I have one confusion though; is there a flag that needs to be set, if the library is needed to be compiled with fgt support?

-DWITH_FGT=ON, e.g. if you're using a build/ subdirectory:

$ mkdir build && cd build && cmake .. -DWITH_FGT=ON -DCMAKE_BUILD_TYPE=Release

@VShawn
Copy link

VShawn commented May 29, 2024

I certain that the performance issue originates from gauss_transform.cpp in rigid case.

With the same data, using the original GaussTransformDirect::compute took 2.7 seconds.

image

After I modifying GaussTransformDirect::compute, the time decreased to 0.005 seconds.

image

Unfortunately, the modified GaussTransformDirect::compute I created clearly has issues with the calculation results.

BTW, here the test results on the fgt using the same data.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants