G'MIC extremely slow to compile - fix available

(G'MIC staff) #21

Improvement in compilation times is actually strange, there are no reasons it should be faster to compile with cmake. We have to check if the flags (e.g. optimization flags) passed to the compiler are indeed the same as the regular Makefile :slight_smile:
Anyway, @saknopper has done a wonderful job for sure !

(Sander Knopper) #22

Thanks! Actually, if @KaRo is using the dynamic linking option it might be a lot faster to compile… :wink:

Otherwise it might be due to the lack of optimization flags by default for the cmake build.

(G'MIC staff) #23

Yes, I’ve just checked that, and doing cmake . then, make indeed compiles without optimization flags. This is a bit annoying, I think many users could be cheated by that, and get very slow binaries of gmic as default.
Could we set the release mode as default ?

(Karsten R) #24

I did not use dynamic linking. In fact at least the cli is not optimized.

gmic follic tic +dilate_oct 31 erode_oct. 31 -. … toc

delivers an eight-fold time needed!

(G'MIC staff) #25

Actually, even with

cmake -DCMAKE_BUILD_TYPE=Release .

the generated Makefile does not enable the optimization flags for the compiler. This is a big concern.
Right now, if packagers decide to use the current CMakeLists.txt, they may end up with a wrong, unoptimized version of G’MIC !

(Sander Knopper) #26

I will fix it, don’t worry :slight_smile: You haven’t made a new release yet right?

(Flössie) #27

While you’re at it: You could also add some eye candy by streamlining capitalization (IF, SET vs. if, set) and modernizing with else() and endif() (where applicable). :slight_smile:

(Morgan Hardwood) #28

You can run this script in the root of your repo to fix CMake command case and spaces between command and braces: