Issue metadata
Sign in to add a comment
|
70KB regression in resource_sizes (MonochromePublic.apk) at 553578:553597 |
||||||||||||||||||||||
Issue descriptionCaused by “[typedarray] Implement TypedArray.p.sort using Torque.” Commit: 3ea1ad234c17cb51d09fd2b97f286b0753b3c147 Link to size graph: https://chromeperf.appspot.com/report?sid=a097e74b1aa288511afb4cb616efe0f95ba4d347ad61d5e835072f23450938ba&num_points=10&rev=553587 Debugging size regressions is documented at: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/apk_size_regressions.md#Debugging-Apk-Size-Increase It looks like it is an increase of 68kb in the size of v8/snapshot_blob_32.bin. It's not clear to me whether or not this increase was expected. Please have a look and either: Close as “Won't Fix” with a short justification, or Land a revert / fix-up.
,
Apr 26 2018
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8948164547751332528
,
Apr 26 2018
Supersize output:
Section Legend: t=.text, r=.rodata, R=.data.rel.ro, d=.data, b=.bss, x=.dex, m=.dex.method, p=.pak.translations, P=.pak.nontranslated, o=.other
Index | Running Total | Section@Address | Δ PSS (Δ size_without_padding) | Path
------------------------------------------------------------
~ 0) 67652 (97.1%) o@0x0 67652 (1163780->1231432) v8/snapshot_blob_32.bin
~ 1) 70012 (100.5%) o@0x0 2360 (0->0) {no path}
Overhead: APK file
~ 2) 69632 (99.9%) o@0x0 -380 (179654->179274) v8/natives_blob.bin
+ 3) 69557 (99.8%) r@0x0 -75 (0->0) {no path}
** aggregate padding of diff'ed symbols
~ 4) 69487 (99.7%) o@0x0 -70 (0->0) {no path}
Overhead: ELF file
~ 5) 69519 (99.7%) t@0x14cf300 32 (6744->6776) v8/src/isolate.cc
v8::internal::Isolate::Init
+ 6) 69550 (99.8%) r@0x7daf7 31 (0->31) v8/src/interface-descriptors.cc
string literal
+ 7) 69574 (99.8%) r@0x17346c 24 (0->24) v8/src/builtins/builtins.cc
string literal
~ 8) 69598 (99.9%) t@0x1305ed0 24 (18644->18668) v8/src/bootstrapper.cc
v8::internal::Genesis::InitializeGlobal
+ 9) 69622 (99.9%) R@0x28c7308 24 (0->24) v8/src/isolate.cc
v8::internal::TypedArrayQuickSortDescriptor [vtable]
~ 10) 69646 (99.9%) R@0x28b20a8 24 (9132->9156) v8/src/builtins/builtins.cc
v8::internal::builtin_metadata
+ 11) 69666 (100.0%) r@0x14c58d 20 (0->20) v8/src/builtins/builtins.cc
string literal
~ 12) 69646 (99.9%) t@0x1342f60 -20 (1252->1232) v8/src/compiler.cc
v8::internal::Compiler::Compile
+ 13) 69658 (99.9%) R@0x0 12 (0->0) {no path}
** aggregate padding of diff'ed symbols
+ 14) 69650 (99.9%) t@0x0 -8 (0->0) {no path}
** aggregate padding of diff'ed symbols
~ 15) 69658 (99.9%) t@0x1334434 +8 (2072->2080) v8/src/builtins/builtins.cc
v8::internal::Builtins::CallableFor
~ 16) 69666 (100.0%) t@0x15c0f7c +8 (376->384) v8/src/runtime/runtime-regexp.cc
v8::internal::StringReplaceGlobalAtomRegExpWithString<>
~ 17) 69672 (100.0%) t@0x1334cb4 +6 (1482->1488) v8/src/builtins/builtins.cc
v8::internal::Builtins::IsIsolateIndependent
~ 18) 69678 (100.0%) t@0x15c10fc +6 (384->390) v8/src/runtime/runtime-regexp.cc
v8::internal::StringReplaceGlobalAtomRegExpWithString<>
~ 19) 69682 (100.0%) R@0x28c4630 +4 (556->560) v8/src/interface-descriptors.cc
.Lswitch.table._ZNK2v88internal23CallInterfaceDescriptor9DebugNameEPNS0_7IsolateE
~ 20) 69686 (100.0%) t@0x15e814c +4 (384->388) v8/src/snapshot/builtin-deserializer-allocator.cc
v8::internal::BuiltinDeserializerAllocator::CreateReservationsForEagerBuiltinsAndHandlers
~ 21) 69690 (100.0%) t@0x15e8334 +4 (432->436) v8/src/snapshot/builtin-deserializer-allocator.cc
v8::internal::BuiltinDeserializerAllocator::InitializeFromReservations
~ 22) 69686 (100.0%) t@0x15f06fe -4 (26->22) v8/src/snapshot/snapshot-common.cc
v8::internal::BuiltinSnapshotData::Payload const
~ 23) 69682 (100.0%) t@0x14ceea8 -4 (780->776) v8/src/isolate.cc
v8::internal::Isolate::~Isolate
~ 24) 69684 (100.0%) o@0x0 +2 (71584->71586) MonochromePublic.apk/other/META-INF/MANIFEST.MF
~ 25) 69686 (100.0%) t@0x15e8bc8 +2 (14->16) v8/src/snapshot/builtin-snapshot-utils.cc
v8::internal::BuiltinSnapshotUtils::IsBuiltinIndex
~ 26) 69688 (100.0%) t@0x1334ca0 +2 (18->20) v8/src/builtins/builtins.cc
v8::internal::Builtins::IsEmbeddedBuiltin
~ 27) 69690 (100.0%) t@0x14673e8 +2 (1024->1026) v8/src/heap/factory.cc
v8::internal::Factory::NewSharedFunctionInfo
~ 28) 69688 (100.0%) t@0x14d2068 -2 (48->46) v8/src/isolate.cc
v8::internal::Isolate::FireMicrotasksCompletedCallback
******************************Resource Sizes Diff******************************
MonochromePublic.apk_Breakdown (+69,699 bytes)
+2,360 bytes Zip Overhead
+67,272 bytes V8 Snapshots size
+64 bytes Native code size
+3 bytes Package metadata size
MonochromePublic.apk_Specifics
+69,699 bytes normalized apk size
+64 bytes main lib size
,
Apr 26 2018
I am not sure who to assign this to since szuend@ is not a chromium member. jgruber@ would you mind taking a look and assigning to the right person?
,
Apr 27 2018
70K seems like a bit excessive for a single builtin. In this case, it's understandable because we inline a copy of the sorting algorithm for each of the 11 typed array elements kinds. The only real way to significantly reduce the size would be to dispatch based on the elements kind at each use-site (e.g. each Load and Store) instead of inlining 11 copies of the entire algorithm. I'm not sure how much that'd affect performance though. We might have to take this..
,
May 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/d0ecfe25d607412e7ab85eac2e9d714466eea668 commit d0ecfe25d607412e7ab85eac2e9d714466eea668 Author: Simon Zünd <szuend@google.com> Date: Thu May 03 08:18:28 2018 [typedarray] Change Torque sort implementation This CL changes how TypedArray.p.sort is implemented in Torque, mainly to address the binary memory size of the builtin. With this CL the memory comes down from 53611 to 4215 (as reported by --print-builtin-size on a x64.release build). With the following performance impact on the relevant benchmarks: Benchmark Original (JS) Torque (initial) This CL IntTypes 83.9 263.7 202.3 BigIntTypes 32.1 54.6 47.2 FloatTypes 99.3 138.7 109.3 This is achieved by pushing the Load/Store dispatch based on the elements kind into separate builtins that are executed for each load/store. This results in only one version of the sorting algorithm instead of one version per elements kind. R=jgruber@chromium.org Bug: chromium:837282 Change-Id: I7fe2da3cbfd01531d070128126a0d56d3dd6bdcc Reviewed-on: https://chromium-review.googlesource.com/1033744 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52937} [modify] https://crrev.com/d0ecfe25d607412e7ab85eac2e9d714466eea668/src/builtins/base.tq [modify] https://crrev.com/d0ecfe25d607412e7ab85eac2e9d714466eea668/src/builtins/builtins-definitions.h [modify] https://crrev.com/d0ecfe25d607412e7ab85eac2e9d714466eea668/src/builtins/builtins-typed-array-gen.cc [modify] https://crrev.com/d0ecfe25d607412e7ab85eac2e9d714466eea668/src/builtins/typed-array.tq
,
May 3 2018
Fixed by #6. 👍!
,
May 3 2018
,
May 7 2018
,
May 29 2018
Issue 837528 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Apr 26 2018