On Thu, 2011-10-20 at 20:20 +0200, Patrick Ohly wrote:
> On Thu, 2011-10-20 at 15:37 +0200, jacqueline.leroi wrote:
> > can anyone tell me How can i get the minimum size of syncevolution
> > binary and for the synthesis library ?
>
> Which size? The files on disk?
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
