[SAMPLE_CONSENSUS] Optimize Ellipse3D build performance with extern templates and logic relocation

[AlrIsmail]

This PR is a continuation of #6430 and a more detailed investigation of @larshg's commit, which relocates internal large math logic from the header to the source file and implements extern template declarations for SampleConsensusModelEllipse3D.

Impact

ClangBuildAnalyzer reports :
baseline.txt -> opt.txt

Metric	Baseline (Inline)	Optimized (Extern)	Delta
Codegen	281.4 s	275.8 s	-5.6 s
Parsing	173.7 s	172.4 s	-1.3 s
Compilation Time (Unit Test)	21.5 s	14.2 s	-7.3 s
Ellipse3D Source Build	35.9 s	35.1 s	-0.8 s
Runtime (100 RANSAC runs)	8.33 ms	8.23 ms	-0.1 ms

[mvieth]

Thank you for the pull request, but I do not see any improvement in build times when I do the measurements:

master         new
13m51.421s     13m53.709s       everything up to and including test_quadric_models, gcc
 9m37.505s      9m37.639s       pcl_sample_consensus, gcc
 0m27.086s      0m26.738s       test_quadric_models, gcc
 0m51.993s      0m52.695s       only ellipse3d.cpp, gcc
 0m50.178s      0m50.271s       only ellipse3d.cpp, clang
 7m8.413s       7m11.149s       pcl_sample_consensus, clang
 0m19.962s      0m19.446s       test_quadric_models, clang
 0m17.814s      0m18.138s       test_quadric_models, clang

It seems like you are basing your metrics on only two runs of the clang build analyzer? One for the baseline, once for the changed version? That is not very robust. The differences in build time could easily be due to randomness. In fact, many files have faster build times in opt.txt than in baseline.txt, which cannot be explained by your changes to sac_model_ellipse3d.h and sac_model_ellipse3d.cpp. Perhaps you computer had other background processes running while building the baseline, and was slower du to that.

[AlrIsmail]

It's actually strange that you don't see improvement or maybe beacue i'm on an arm64 architecture?

As to respond to your question, I did do a couple of runs of clang build analyzer, but didn't stress test it (is the clang build analyzer susceptible to noise ?)
And so I redid a 10-run cold-cache benchmark suite (42 times compilation each) to make sure, and I still get the improvements (those are averages):
Parsing: 133.6s → 125.2s (-8.4s savings)
Codegen: Delta of -1.8s (within noise)

Do you have a more accurate way to test it if we are not sure of the results?

[mvieth]

maybe beacue i'm on an arm64 architecture?

I can't rule that out, but I also can't think of a reason why that would make a big difference.

As to respond to your question, I did do a couple of runs of clang build analyzer, but didn't stress test it (is the clang build analyzer susceptible to noise ?)

I did notice some peculiarities in the clang build analyzer output in the past, which makes me not trust it completely when it comes to absolute timings (for analyzing what classes/functions take longest to build it is still useful of course). I measured the absolute compile time with the time command line utility on Ubuntu, building with a single thread.

And so I redid a 10-run cold-cache benchmark suite (42 times compilation each) to make sure, and I still get the improvements (those are averages):

I am confused, in your original impact analysis, "Codegen" showed the biggest improvement, but now "Parsing" shows the biggest improvement while "Codegen" only changes rather little?
Besides, I see no reason why this change would improve the build time by several seconds. Sure, parsing the full definition of three functions takes a little bit of time (compared to only parsing the function declarations), but I cannot imagine that this makes a difference of several seconds?
Also, do you see the improvement when compiling sac_model_ellipse3d.cpp or test_sample_consensus_quadric_models.cpp? Then I know which build times I should measure again.