StarGeometry.so size difference from SL16d to DEV...

From SL16d to DEV, the size of the StarGeometry.so library has increased by a factor of ~3.  From ~60 MB to ~180 MB.

We have added a few new geometry models since SL16d, but this cannot explain the increase in size.
  • For comparison, the FORtran xgeometry.so library increased as well, from ~5 to ~6 MB. 
  • There are additional subroutines added to xgeometry.so to assist in steering the creation of the geometry which probably accounts for the observed increase.
AgML 2.0 was integrated after SL16d.  This upgrade to AgML changed the way that AgML data structures are handled.  It removed dependencies on the ROOT dictionaries, replacing them with dictionary objects created at compile time.    Some increase is expected, but a factor of 3?

There is one geometry model which does not rely on AgML data structures.  ShapGeo.xml is a simple example which creates the geant3 primitives.

Looking at the official library builds in SL16d and DEV, the size of the ShapeGeo.o object file changes from 0.8 MB to 1.4 MB.  Nearly a factor of 2.

Looking at the compilable ShapeGeo.{h,cxx} codes, the only difference is the inclusion in DEV of two header files... AgMLStructure.h and stddef.h... neither of
which are required for this geometry module.  Upon commenting these out, the object file remains at 1.4MB.

Are we compiling at different levels of optimization / how big of an effect on file size?

DEV build:
g++ -m32 -fPIC -pipe -Wall -Woverloaded-virtual -std=c++0x -Wno-long-long -pthread -O1 -g -Dsl73_gcc485 -D__ROOT__ -DNEW_DAQ_READER -I. -I.sl73_gcc485/include -I/afs/rhic.bnl.gov/star/packages/DEV -I/afs/rhic.bnl.gov/star/packages/DEV/StRoot -I/afs/rhic.bnl.gov/star/packages/DEV/.sl73_gcc485/include -I/afs/rhic.bnl.gov/star/ROOT/5.34.38/.sl73_gcc485/rootdeb/include -c .sl73_gcc485/obj/StarVMC/StarGeometry/ShapGeo.cxx -o .sl73_gcc485/obj/StarVMC/StarGeometry/ShapGeo.o
SL16d build:
g++ -m32 -fPIC -pipe -Wall -Woverloaded-virtual -std=c++0x -Wno-long-long -pthread     -g -Dsl73_gcc485 -D__ROOT__ -DNEW_DAQ_READER -I. -IStRoot -I.sl73_gcc485/include -I/afs/rhic.bnl.gov/star/packages/SL16d -I/afs/rhic.bnl.gov/star/packages/SL16d/StRoot -I/afs/rhic.bnl.gov/star/packages/SL16d/.sl73_gcc485/include -I/afs/rhic.bnl.gov/star/ROOT/5.34.30/.sl73_gcc485/rootdeb/include -c .sl73_gcc485/obj/StarVMC/StarGeometry/ShapGeo.cxx -o .sl73_gcc485/obj/StarVMC/StarGeometry/ShapGeo.o
Appears that the -O1 optimization flag is resulting in the increased library file size.  (Confirmed by compiling in DEV w/out the flag).

Q1: Do we benefit from a smaller memory footprint for the geometry shared library.
Q2: Do we need to compile the geometry optimized?

What is the overhead of the AgML 2.0 data structures?

As noted above, we have added a set of dictionary classes to the StarGeometry.so library in order to manage the AgML data structures.  To guage the impact, look at the object file size when building TpceGeo3a.xml...

In SL16d, TpceGeo3a.o is 1.5 MB
In DEV (-O1), TpceGeo3a.o is 2.7 MB
In DEV (no opt), TpceGeo3a is 2.1 MB

So, reducing the optimization level would reduce the library size, but there is still a significant overhead from AgML 2.0.

Compiling w/out -O1, StarGeometry.so is 89MB.