On Tue, Jun 20, 2017 at 10:28 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 06/20/2017 12:28 PM, Nathan Froyd wrote: > >> On Tue, Jun 20, 2017 at 12:19 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> >> wrote: >> >>> On 06/20/2017 08:34 AM, Nathan Froyd wrote: >>> >>>> There is some kind of interaction with the underlying machine (see >>>> comment 104 in said bug, where the binaries perform identically on a >>>> local machine, but differently on infrastructure), but we haven't >>>> tracked that down yet. >>>> >>> From comment 104 it seems that it is possible to reproduce the slowdown >>> from >>> the unstripped cross builds locally. Has anyone profiled one of these >>> builds comparing them to an unstripped non-cross build to see where the >>> additional time is being spent? I couldn't tell from the bug if this >>> investigation has happened. >>> >> My understanding is that the slowdown cannot be reproduced on local >> developer machines, but can be reproduced on loaner machines from >> infra. >> > Huh. That's interesting and even more puzzling... > >> I don't think anybody has tried profiling on infra to see >> where time differences are. >> > That seems like the obvious next step to investigate to me. We should > *really* only talk about stripping builds as the last resort IMO, since we > have way too many developers using OSX every day... > I would argue it is in our best interest to have as little divergence between Firefox release channels as possible. Today, Nightly is distributed with symbols and Beta/Release/ESR all ship without symbols. There are other variations between the build configurations as well. Every variation between channels increases the risk of introducing bugs or other undesired behavior and that said behavior won't be detected until weeks after it has landed on central (we can run CI for these variations, sure, but that's no substitute for a user base). It should not be a controversial statement to say that variation between build configurations / channels is not ideal. In the case of debug symbols, we've historically made the trade-off that symbols are useful to developers using Nightly, they don't appear to have a significant downside (other than package/download size), so why not ship them. We've accepted the risk of this variation in the Nightly channel in return for not inconveniencing developers. What's happening now is that we have a new problem caused by debug symbols for cross builds and we are re-assessing whether the trade-off to ship debug symbols on Nightly is still justified. If it is, then there may be considerable work to preserve the status quo. I understand stripping Nightly would be inconvenient and I personally don't want to do it for this reason. But the flip side is we converge the configurations for Nightly and Beta, which I argue is a good thing. FWIW, I'd like to point out that Chrome Canary (Nightly equivalent) doesn't ship debug symbols for MacOS (assuming my methodology of running `nm --debug-syms` is correct). While this is quite possibly due to Chrome having closed source components, their developers have obviously found a way to work without debug symbols on shipped builds. I'd like to think that if Chrome has figured out how to make it work, we can too. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
