[Dev] Tizen 3.0 : Optimizing applications launch time
stephane.desneux at eurogiciel.fr
Thu Oct 24 19:06:29 GMT 2013
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:
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.
Intel OTC - Vannes/FR
More information about the Dev