[Dev] Tizen 3.0 : Optimizing applications launch time

Stéphane Desneux stephane.desneux at eurogiciel.fr
Mon Oct 21 10:51:46 GMT 2013


On 21/10/2013 10:13, Łukasz Stelmach wrote:
> It was <2013-10-18 pią 20:16>, when Stéphane Desneux wrote:
>> Conclusion: stripping the binaries has a great impact:
>> - smaller image size: faster to load from storage,
>
> AFAIK this is not true. Linker does not read(2) libraries, it mmap(2)s
> them and accesses only the parts it needs. This is how shareing the code
> works. This might be true if you do some kind of prefetch or something.

You're right: shared libs are mmaped by ld.so as you described. This is 
also confirmed by the small gain on boot times.

>> faster to download from tizen.org (and more bandwidth for everyone
>> ;-)) - faster application launch, at least for WRT
>
> True.

The impact seems interesting for the launchpads (which preload some libs 
with dlopen()).

>> Next week, I'll check more precisely why we gain 75% on the binary
>> size: perhaps a few libs are responsible for this... Or is this
>> globally distributed over all the binaries ?

I found the lib responsible for the extra 1.2GB on tizen/common: it's 
/usr/lib64/libewebkit2.so . Other libs are not that big, stripped or 
not. => some specific fitness program should be applied on this lib :-)

> Please remember that we need those symbols for crash diagnostics. You
> might want to refer to Fedoras ABRT[1] to see how a good crash reporting
> system looks like. If I don't make things up, Fedora keeps some debuging
> symbols to improve the process.
>
> [1] https://fedoraproject.org/wiki/Features/ABRT?rd=Features/CrashCatcher

ABRT seems to be able to download the debuginfos on the fly to produce 
more meaningfull dumps. But for Tizen it's probably not a good idea as 
we don't want to fill the user device with debug files !

So we have to keep enough information in binaries to have good dumps.

I wonder if the crashreporter can produce correct reports with partially 
stripped binaries: I mean we could strip the .debug_info section 
(responsible for the extra weight) but keep the other symbols to have 
meaningful backtraces. i.e running 'strip --strip-debug' instead of 
'strip --strip-all'.

-- 
Stéphane Desneux
Intel OTC - Vannes/FR


More information about the Dev mailing list