Re: [SyncEvolution] syncevolution + file size

On Thu, 2011-10-20 at 20:20 +0200, Patrick Ohly wrote: The question was indeed about disk usage. A minimal compilation into a single executable is done with this: <path to SyncEvolution source>/configure \ --with-synthesis-src=<path to libsynthesis> \ --disable-shared \ --enable-static \ --disable-ecal --disable-ebook --disable-bluetooth This leaves only the file backend enabled and disables direct syncing with a phone via Bluetooth. The result is a stripped "syncevolution" binary of 3.2MB. ~600KB of that is string data, mostly in the dynamic symbol table. This is for loading backends dynamically (they need these symbols). If loading backends is not needed, the --export-dynamic can be dropped from the link line (has to be done manually), resulting in a stripped binary of 2.7MB. This is the minimum size including a functional SyncEvolution command line. Removing the command line and some of its support code could be done by adding more ifdefs, but I don't know how much that really would trim from the files. The libsynthesis also has a lot of optional features that could be turned off. Some of these are currently needed by SyncEvolution, though, like for example the XML config mechanism. A large chunk of code and text strings are due to the logging facilities. This can be disabled in target_options.h. However, this feature is important and hasn't been turned off for a while. The code doesn't even compile without it unless further changes are made. After enough changes to get the code to compile (probably not correct, though) the result is a binary of 2.4MB. Alternatively, one can also configure with CFLAGS=-Os CXXFLAGS=-Os. This together with dropping --export-dynamic reduces the size to 2MB. Everything together (no logging, -Os, no --export-dynamic) results in 1.8MB. My takeaway from this experiment is that * Inlining code and unrolling seem to inflate the code quite a bit; synchronization is mostly network and disk IO bound, so perhaps using -Os is worthwhile. * A more selective exporting of symbols from the main binary could reduce the size without loss of functionality or speed. Quite the opposite, load times would be improved (less work for the dynamic linker at runtime). However, finding the right set of symbols is a bit of work. Can you say a bit more about your goals? Are you trying to fit synchronization into an embedded device with a very low size for the filesystem? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.