New issue
Advanced search Search tips

Issue 644757 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression

Blocking:
issue 599327



Sign in to add a comment

1.3% regression in sizes/libcronet.so on android_cronet_arm64_builder at 416818:416819

Project Member Reported by jbudorick@chromium.org, Sep 7 2016

Issue description

Performance dashboard identified a 1.3% regression in sizes/libcronet.so on android_cronet_arm64_builder at revision range 416818:416819. Graph: https://chromeperf.appspot.com/report?masters=ChromiumAndroid&bots=android_cronet_arm64_builder&tests=sizes%2Flibcronet.so&checked=libcronet.so%2Clibcronet.so_ref%2Cref&rev=416819

This is due to the NDK roll.
 
Blocking: 599327
I've been looking at this some this morning. Many of the object files got significantly larger when compiled with the version of gcc in NDK r12b (a 2015 4.9.x build) compared to the same files compiled with the version of gcc in NDK r10e (a 2014 4.9.x build). No compile flags changed in the switch.

I'm going to spend some time looking at the gcc release notes since 4.9 when I get a chance.
of note, though: gcc is deprecated in favor of clang in the NDK as of r11: https://developer.android.com/ndk/downloads/revision_history.html

I tried building w/ clang as well, but neither the version in the NDK nor the version in //third_party/llvm-build/Release+Asserts/ work, even w/ a few gn changes. We could look at this further, though.

Comment 4 by thakis@chromium.org, Sep 12 2016

We have an android clang bot, so the version in third_party/llvm-build/Release+Asserts definitely should work (it has bot coverage on some archs).
hmm, maybe I'm not configuring it correctly then.

Comment 6 by thakis@chromium.org, Sep 12 2016

Just `is_clang = true` in your args.gn should be enough.

Here's one bot I know of (https://build.chromium.org/p/chromium.fyi/builders/ClangToTAndroidASan -- currently red 'cause that one uses trunk clang and trunk clang is apparently broken, but we have some bots on the internal waterfall using pinned clang too I think.)
On arm, that's true.

On arm64, it isn't:
 - boringssl's assembly complains. Fixable by changing https://codesearch.chromium.org/chromium/src/third_party/boringssl/BUILD.gn?rcl=0&l=73 s.t. we use -fno-integrated-as on arm64
 - base/strings/string_util.h complains about macro expansion in the snprintf declaration in //base/strings/string_util.h. Still looking for a fix.

Comment 8 by thakis@chromium.org, Sep 12 2016

arm64 + clang is  bug 539781 
Ah. Starred.
(See also thread "[chromium-dev] Chromium browser Clang build - any progress ?" from a while ago. As far as I understand, this used to roughly work at some point earlier this year -- but we don't have bots for that.)
Labels: Performance
Status: WontFix (was: Assigned)
This regression has been included in a stable release and that stable channel is now deprecated. I'm closing this so that we won't have unresponsive performance regressions in the future. 

Sign in to add a comment