Optimize compilation speed and binary size

[Daandelange]

Everything works great, compilation is smooth and works out-of-the-box. But now I have a Number Object that takes as much time to compile as Mosaic does, plus it's the same size. (+50Mb !!) Apparently, all symbols are duplicated into the plugin binary. Did I miss something ?

What are your findings and explorations around this ? I guess there's a reason for this [temporary?] choice ? I just checked the recently new ofxHotReloader and the plugin is a little over 10Mb, which is about the size of OF, so it probably has the same approach.

Theoretically, there should be a way to simply compile the plugin code in a few bytes, then link that against the symbols included in the Mosaic binary ? Maybe Mosaic should link with a stand-alone OpenFrameworks.a (.bundle?), then the plugins do the same ?

[d3cod3]

Yes, everything you're saying is a temporary situation, i had priority in make it work smoothly and easy, now the next step will be optimize, in order to reduce plugin size and compile speed.

Basically, we'll need to reorganize the code in order to have the minimum includes as possible to compile an object ( a plugin in this case ), then everything will be lighter and faster to compile.

Right now, every objects depends on PatchObject class

that needs:

ofxImGui ofxFontStash ofxPDSP ofxXmlSettings

and most of the core/ files in ofxVisualProgramming

then, starting by creating a specific version of ofxVisualProgramming ( maybe call it ofxMosaicPlugin? ) just for plugin compiling, we'll reduce a lot the plugin size and the compile time.

ofxHotReloader is based on the older ofxPlugin, both tested a while ago, but the smoother and bugless option was the one i used with PUGG, so i stayed on that, but yes, the principle is similar, the plugin carry a lot of unnecessary symbols at runtime, but necessary for compile the dynamic lib.

More optimizations will be possible too, as you suggest, so let's start digging the issue!

[Daandelange]

Ok, good to hear. So there seem to be 2 aspects on this issue :

1. Reduce the plugin includes & dependencies (easy)
2. Figure out how to make Mosaic and Mosaic-Plugin against the same OF library (and other shared ones?). 2.a Compile OF as a (dynamic/static?) shared library, link both against it. 2.b Link the plugins against the OF contained within Mosaic ?

This will probably also bring changes to the OF API mappings / bridging. (maybe solving the duplicate singletons issue with the renderers ?)

Anyways, there seem to be some half-answered topics around this. [ -1- / -2- / -3- / -4- / -5- ]

• Some interesting notes on different approaches
• An alternative to Pugg.
• Linking the DLL against Mosaic's embedded OF is possible ?

Edit: I've been digging this a bit. This is gonna get complicated, leaving this for later. The solution mentioned in the last link (above) looks the best, but I haven't succeeded replicating it with Qt. Recommendations and existing implementations seem to restrict plugin compilation to use only shared dylibs, when code is shared between host and plugins. That would mean : make ImGui Shared, make OF shared, make (parts of?) ofxVP shared, etc.

[d3cod3]

Fixed point 1!

https://github.com/d3cod3/ofxMosaicPlugin

compile time drastically reduced and binary size at ~= 27% of the previous size, not bad