Significantly inflated executable size using later CGAL libraries
As some of you know, in my matlab meshing toolbox (iso2mesh), I embedded
a few modified CGAL demo utilities. In the past, these utilities were
statically compiled and distributed along with my toolbox. I saw there
was a push to migrate to the newer CGAL releases
last year, I had added the compilation scripts
(https://github.com/fangq/iso2mesh/tree/master/tools) to compile these
tools and link with the newer versions of CGAL, but noticed one problem:
the binaries compiled/linked using the newer CGAL libraries (~4.10 or
newer) are dramatically (5x to 10x) larger than the older libraries
I got even more surprised as I started packaging iso2mesh for Fedora
over the past few days
the binaries generated on CGAL 4.14/Fedora 30 are even bigger than I've
seen before - the 3D mesher code (cgalmesh) grows to 67MB compared to
4.5MB using CGAL 3.8 (15x), and mesh_polyhedral mesher (cgalpoly)
example produced a 90 MB executable compared to 4.3 MB previously.
I am wondering if there is a way (a link/compile flag?) that I can
reduce the binary size? loading a large executable is quite inefficient
because disk reading is very slow compared to execution. I could use an
exe packers, such as upx, to compress the exe by about 9-fold, but they
are still several fold larger than what they used to be (after packing).
Re: Significantly inflated executable size using later CGAL libraries
On Tuesday, October 8, 2019 1:12:08 AM CEST Qianqian Fang wrote:
> the binaries generated on CGAL 4.14/Fedora 30 are even bigger than I've
> seen before - the 3D mesher code (cgalmesh) grows to 67MB compared to
> 4.5MB using CGAL 3.8 (15x), and mesh_polyhedral mesher (cgalpoly)
> example produced a 90 MB executable compared to 4.3 MB previously.
As discussed with Qianqian Fang on the Fedora bug tracker , the binaries
were compiled with debug symbols. Once stripped,
- cgalpoly is 2.7MB,
- cgalmesh is 2.0MB.
That looks like even smaller than the numbers announced with CGAL-3.8.