[Dev] Tizen 3.0 : Optimizing applications launch time

Stéphane Desneux stephane.desneux at eurogiciel.fr
Thu Oct 24 19:06:29 GMT 2013

Hi Brad,

Peters, Brad T wrote:
> Hi Stéphane,
> I'm a fervent believer in first-crash data capture, especially when you're
> environment is
> unstable to begin with (ie 3.0). Installing debug packages after the fact requires
> reproducing the issue, which may or may not happen and wastes time.

I agree with that. But we should note somewhere (in a bug, a feature on Jira for 
example) that "releasing" implies a full strip of the binaries (it's easy to 
forget that point when releasing). Perhaps this is something to be added earlier 
in the release cycle, to have QA teams work on snapshots that would be as close 
as possible to the release image.

Anyway, for TZ 3.0, we can keep rpm as is for the moment.

> That said, it looks like 3.0 binaries are already partially stripped (check out
> this patch:
> https://review.tizen.org/gerrit/gitweb?p=platform/upstream/rpm.git;a=commit;h=343c985ee3f8e027386fec73da1c63f827e48a03
> )

I investigated on "semi-stripped" binaries lately and found the same patch from 
William Douglas. Duplicate brains ;-)

My discovery is that:
- checking if a binary is stripped with /usr/bin/file is approximative. I mean 
that if a binary contains only symbol sections (and no debug), /usr/bin/file 
will report the binary as 'non stripped'. This is not false, but that's not the 
information we want :-) On the opposite, when /usr/bin/file says that a binary 
is "stripped", it's right: no debug, no symbols.
- so we have to analyze further to detect the "badly" stripped binaries, those 
stoll containing debug sections. One good candidate is webkit, that has 1.2GB in 
debug sections !

=> there's at least a webkit specific bug to open.

Tomorrow, I'll check the "bad" binaries and report on this.

> For 2.x, perhaps we could back-port this patch.
> I recommend opening a bug for 2.2 and one for 2.1. We should definitely be
> stripping binaries there,
> even if retaining symbol information as with that patch

It makes sense.

Thanks for your feedback.
Stéphane Desneux
Intel OTC - Vannes/FR

More information about the Dev mailing list