Bug 1437872 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

With a LTO build and all patches applied, the improvement is even a bit larger:
``
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%    +157  +0.0%    +157    .dynstr
  +0.0%    +153  [ = ]       0    .debug_pubtypes
  +0.0%    +136  [ = ]       0    .debug_frame
  +0.0%     +56  +0.0%     +30    [4 Others]
  +0.0%     +48  [ = ]       0    .debug_aranges
  +0.0%     +48  +0.0%     +48    .rela.dyn
  +0.0%     +32  +0.0%     +32    .data.rel.ro
 -20.2%    -235 -20.2%    -235    [LOAD #1 [R]]
  -0.0% -1.12Ki  -0.0% -1.12Ki    .eh_frame_hdr
  -0.0% -1.20Ki  [ = ]       0    .debug_abbrev
  -0.0% -3.16Ki  -0.0% -3.16Ki    .rodata
  -0.0% -3.66Ki  [ = ]       0    .symtab
 -66.2% -4.06Ki  [ = ]       0    [Unmapped]
  -0.0% -5.32Ki  -0.0% -5.32Ki    .eh_frame
  -0.0% -12.5Ki  [ = ]       0    .strtab
  -0.2%  -162Ki  -0.2%  -162Ki    .text
  -0.1%  -174Ki  [ = ]       0    .debug_str
  -0.2%  -197Ki  [ = ]       0    .debug_line
  -0.3% -2.13Mi  [ = ]       0    .debug_info
  -4.3% -2.44Mi  [ = ]       0    .debug_ranges
  -1.0% -4.02Mi  [ = ]       0    .debug_loc
  -0.4% -9.13Mi  -0.1%  -171Ki    TOTAL
```

On the symbol level, this breaks down to:
```
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  [NEW]  +134Ki  [NEW]  +115Ki    mozilla::detail::VectorStorage<>::growStorageBy()
  +184% +35.2Ki  +185% +35.2Ki    js::jit::CacheIRCloner::cloneOp()
  [NEW] +15.1Ki  [NEW] +15.0Ki    js::gc::GCRuntime::beginMarkPhase()
  [NEW] +8.98Ki  [NEW] +7.61Ki    mozilla::detail::VectorStorage<>::growTo()
  +169% +8.94Ki  +172% +8.94Ki    js::ctypes::CType::GetName()
  [NEW] +8.05Ki  [NEW] +6.76Ki    mozilla::detail::VectorImplCommon<>::convertToHeapStorage()
  +120% +7.54Ki  +121% +7.54Ki    ShortestPaths()
  [DEL] -5.97Ki  [DEL] -5.19Ki    mozilla::Vector<>::convertToHeapStorage()
  [DEL] -7.42Ki  [DEL] -6.38Ki    mozilla::detail::VectorImpl<>::growTo()
 -55.5% -8.98Ki -58.2% -8.98Ki    AtomicEffectOp<>()
  -0.0% -5.47Ki  -0.1% -11.0Ki    [3655 Others]
 -16.1% -11.8Ki -16.1% -11.8Ki    js::jit::BaselineInterpreterGenerator::emitInterpreterLoop()
 -46.4% -12.7Ki -47.8% -12.7Ki    AtomicFetchOp<>()
 -47.0% -13.5Ki -47.2% -13.5Ki    js::gc::GCRuntime::incrementalSlice()
 -10.6% -20.5Ki -10.6% -20.5Ki    js::jit::CodeGenerator::generateBody()
  -0.1%  -174Ki  [ = ]       0    [section .debug_str]
  -0.2%  -197Ki  [ = ]       0    [section .debug_line]
  [DEL]  -324Ki  [DEL]  -278Ki    mozilla::Vector<>::growStorageBy()
  -0.3% -2.13Mi  [ = ]       0    [section .debug_info]
  -4.3% -2.44Mi  [ = ]       0    [section .debug_ranges]
  -1.0% -4.02Mi  [ = ]       0    [section .debug_loc]
  -0.4% -9.13Mi  -0.1%  -171Ki    TOTAL
```
Interestingly, the size of some functions (`js::jit::BaselineInterpreterGenerator::emitInterpreterLoop`, `js::gc::GCRuntime::incrementalSlice`, `js::jit::CodeGenerator::generateBody`) decreases significantly, which seems that removing `MOZ_NEVER_INLINE` enables some optimizations that reduce the size?
With a LTO build and all patches applied, the improvement is even a bit larger:
```
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%    +157  +0.0%    +157    .dynstr
  +0.0%    +153  [ = ]       0    .debug_pubtypes
  +0.0%    +136  [ = ]       0    .debug_frame
  +0.0%     +56  +0.0%     +30    [4 Others]
  +0.0%     +48  [ = ]       0    .debug_aranges
  +0.0%     +48  +0.0%     +48    .rela.dyn
  +0.0%     +32  +0.0%     +32    .data.rel.ro
 -20.2%    -235 -20.2%    -235    [LOAD #1 [R]]
  -0.0% -1.12Ki  -0.0% -1.12Ki    .eh_frame_hdr
  -0.0% -1.20Ki  [ = ]       0    .debug_abbrev
  -0.0% -3.16Ki  -0.0% -3.16Ki    .rodata
  -0.0% -3.66Ki  [ = ]       0    .symtab
 -66.2% -4.06Ki  [ = ]       0    [Unmapped]
  -0.0% -5.32Ki  -0.0% -5.32Ki    .eh_frame
  -0.0% -12.5Ki  [ = ]       0    .strtab
  -0.2%  -162Ki  -0.2%  -162Ki    .text
  -0.1%  -174Ki  [ = ]       0    .debug_str
  -0.2%  -197Ki  [ = ]       0    .debug_line
  -0.3% -2.13Mi  [ = ]       0    .debug_info
  -4.3% -2.44Mi  [ = ]       0    .debug_ranges
  -1.0% -4.02Mi  [ = ]       0    .debug_loc
  -0.4% -9.13Mi  -0.1%  -171Ki    TOTAL
```

On the symbol level, this breaks down to:
```
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  [NEW]  +134Ki  [NEW]  +115Ki    mozilla::detail::VectorStorage<>::growStorageBy()
  +184% +35.2Ki  +185% +35.2Ki    js::jit::CacheIRCloner::cloneOp()
  [NEW] +15.1Ki  [NEW] +15.0Ki    js::gc::GCRuntime::beginMarkPhase()
  [NEW] +8.98Ki  [NEW] +7.61Ki    mozilla::detail::VectorStorage<>::growTo()
  +169% +8.94Ki  +172% +8.94Ki    js::ctypes::CType::GetName()
  [NEW] +8.05Ki  [NEW] +6.76Ki    mozilla::detail::VectorImplCommon<>::convertToHeapStorage()
  +120% +7.54Ki  +121% +7.54Ki    ShortestPaths()
  [DEL] -5.97Ki  [DEL] -5.19Ki    mozilla::Vector<>::convertToHeapStorage()
  [DEL] -7.42Ki  [DEL] -6.38Ki    mozilla::detail::VectorImpl<>::growTo()
 -55.5% -8.98Ki -58.2% -8.98Ki    AtomicEffectOp<>()
  -0.0% -5.47Ki  -0.1% -11.0Ki    [3655 Others]
 -16.1% -11.8Ki -16.1% -11.8Ki    js::jit::BaselineInterpreterGenerator::emitInterpreterLoop()
 -46.4% -12.7Ki -47.8% -12.7Ki    AtomicFetchOp<>()
 -47.0% -13.5Ki -47.2% -13.5Ki    js::gc::GCRuntime::incrementalSlice()
 -10.6% -20.5Ki -10.6% -20.5Ki    js::jit::CodeGenerator::generateBody()
  -0.1%  -174Ki  [ = ]       0    [section .debug_str]
  -0.2%  -197Ki  [ = ]       0    [section .debug_line]
  [DEL]  -324Ki  [DEL]  -278Ki    mozilla::Vector<>::growStorageBy()
  -0.3% -2.13Mi  [ = ]       0    [section .debug_info]
  -4.3% -2.44Mi  [ = ]       0    [section .debug_ranges]
  -1.0% -4.02Mi  [ = ]       0    [section .debug_loc]
  -0.4% -9.13Mi  -0.1%  -171Ki    TOTAL
```
Interestingly, the size of some functions (`js::jit::BaselineInterpreterGenerator::emitInterpreterLoop`, `js::gc::GCRuntime::incrementalSlice`, `js::jit::CodeGenerator::generateBody`) decreases significantly, which seems that removing `MOZ_NEVER_INLINE` enables some optimizations that reduce the size?

Back to Bug 1437872 Comment 6