On 2013-01-22 9:45 AM, Marco Bonardo wrote:
On 22/01/2013 15:36, Benjamin Smedberg wrote:
On 1/22/2013 9:28 AM, Axel Hecht wrote:
How are the perf numbers looking?
One of the reasons for asking is that I expect RDF to be part of the
startup and window-open codepaths, at least.
I would not expect PGO to optimize any of the RDF code for speed, even
if they were in the startup codepaths.
Boy howdy do we need to get RDF out of the tree, though!
--BDS
I honestly have the same concerns regarding Storage, unfortunately we
don't have data to tell if disabling PGO on it will affect its many
consumers or not, apart the few talos measures :(
It's possible those won't be affected cause sqlite is built separately
and storage just wraps it, but there's no way to tell if, for example,
the awesomebar or startup may end up being slower until we get enough
telemetry.
Once we determine that disabling PGO on storage actually regresses the
performance, we can re-enable it. But note that unless a given code
path is examined throughout the profiling phase of a PGO build, PGO will
probably have negligible effect on it, if any. The PGO compiler looks
for hot code paths and tries to optimize those, so for example if the
awesomebar doesn't get examined during the profiling (which it isn't),
it is extremely unlikely that turning off PGO on the code responsible
for it would have any noticeable change on performance.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
