inline Gc::inner_ptr

[cijiugechu]

While profiling combined.js, I noticed that the function Gc::inner_ptr had a significantly higher overhead(2.57%) compared to the inner function (finalizer_safe)(0.35%). So I attempted to inline it. After reprofiling, the overhead indeed decreased (though not by much - 1.87%), and the overall performance of the program improved as well.

Comparison:

main:

PROGRESS Richards
RESULT Richards 105
PROGRESS DeltaBlue
RESULT DeltaBlue 108
PROGRESS Encrypt
PROGRESS Decrypt
RESULT Crypto 118
PROGRESS RayTrace
RESULT RayTrace 255
PROGRESS Earley
PROGRESS Boyer
RESULT EarleyBoyer 297
PROGRESS RegExp
RESULT RegExp 59.5
PROGRESS Splay
RESULT Splay 420
PROGRESS NavierStokes
RESULT NavierStokes 268
SCORE 169
undefined

PR:

PROGRESS Richards
RESULT Richards 116
PROGRESS DeltaBlue
RESULT DeltaBlue 118
PROGRESS Encrypt
PROGRESS Decrypt
RESULT Crypto 123
PROGRESS RayTrace
RESULT RayTrace 273
PROGRESS Earley
PROGRESS Boyer
RESULT EarleyBoyer 313
PROGRESS RegExp
RESULT RegExp 61.4
PROGRESS Splay
RESULT Splay 314
PROGRESS NavierStokes
RESULT NavierStokes 277
SCORE 172
undefined

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 50.23%. Comparing base (6ddc2b4) to head (48ecb46).
Report is 454 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4317      +/-   ##
==========================================
+ Coverage   47.24%   50.23%   +2.98%     
==========================================
  Files         476      495      +19     
  Lines       46892    49591    +2699     
==========================================
+ Hits        22154    24911    +2757     
+ Misses      24738    24680      -58     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jedel1043]

Nice catch!

I'm curious if the performance changes when we remove the assert below. Can you check that? Maybe we could potentially change it to a debug_assert if it seems to change perf a lot.

[cijiugechu]

Nice catch!

I'm curious if the performance changes when we remove the assert below. Can you check that? Maybe we could potentially change it to a debug_assert if it seems to change perf a lot.

I tried replacing assert with debug_assert, and the results of most benchmarks didn't change much. However, Splay seems to be an exception—it achieved a significant improvement! (from 420 to 470).

Result:

PROGRESS Richards
RESULT Richards 117
PROGRESS DeltaBlue
RESULT DeltaBlue 120
PROGRESS Encrypt
PROGRESS Decrypt
RESULT Crypto 122
PROGRESS RayTrace
RESULT RayTrace 283
PROGRESS Earley
PROGRESS Boyer
RESULT EarleyBoyer 325
PROGRESS RegExp
RESULT RegExp 60.5
PROGRESS Splay
RESULT Splay 470
PROGRESS NavierStokes
RESULT NavierStokes 277
SCORE 183
undefined

[jedel1043]

Nice! I think Splay uses a lot of tree structures, so speeding up pointer accesses is very beneficial for that benchmark.

[jedel1043]

Looks great!