Le 19/10/13 00:12, Peters, Brad T a écrit :



On Fri, Oct 18, 2013 at 11:16 AM, Stéphane Desneux <[email protected]> wrote:
Hello,

I'm currently investigating with Dominique Le Foll on some ways to improve the application launch time (WRT, OSP or core apps).

Before thinking of checking preloaders and other mechanisms, I just sat down and looked at the actual shared libs we can find in tizen/common (x86_64) and IVI (i586).

First surprise: binaries and libs are *not* stripped.

I don't know the reason why we build and distribute unstripped binaries, except easier debugging (but we have debug packages in the repos...). Does anyone know ?

I think this is absolutely for easier debug; we have 2 crash tools (corewatcher and the Samsung crash tool), 
the later of which relies on embedded symbol information to assemble a bt. Corewatcher is, I believe, able to
work with stripped binaries

Debug symbol, should not be in the image but external to the image. Any good debugger can load external symbols.
 

A quick test on IVI shows that stripping libwebkit2 reduces its size by 20% (38MB => 30MB).

So, I decided to strip everything in /usr/bin and /usr/lib64 on the tizen/common image:
- /usr/bin:   before 67MB   after 58MB  => gain=13%
- /usr/lib64: before 1.2GB  after 407MB => * gain=75% * !!!!

=> the impact on the size is huge. For embedded systems with slow flash drives, it'd be even more noticeable.

And now, some tests. First numbers on my new "stripped" image , second numbers on the original one (not stripped):
- boot time: 15s vs. 16s (gain=6%)
- first WRT app launch (Annex): 3.5s vs 9.5s (* gain=63% *)
- WRT app launch (after first launch): <1s in both cases with any app (this is normal behaviour: we have the WRT launchpad)

=> the gain on app launch is also impressive (this gain is not far from the gain on the libs weight).

----

Conclusion: stripping the binaries has a great impact:
- smaller image size: faster to load from storage, faster to download from tizen.org (and more bandwidth for everyone ;-))
- faster application launch, at least for WRT


3.0 is still quite unstable, so it may be premature to discuss optimizing launch times or space usage. 
For 2.2,however, we should absolutely pursue this. 
I had to go back and check... to my amazement, 2.1 is un-stripped as well.  This should absolutely be changed, 
if we can do so at this late date
Optimizing is not something that you can do at the end of the chain. It's an every day concern not dissimilar to QA.
I would propose that we look at externalising the symbol out of the image, while documented how to debug with symbols in sitting in an external file.

Dominig
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to