Skip to content

Conversation

@ltratt
Copy link
Contributor

@ltratt ltratt commented Dec 13, 2025

This PR in a sense undoes some of the crudeness from #131 in f00740d and then marks a couple of functions we definitely don't want outlined. Overall with jitc_yk this slightly speeds up ~four benchmarks and leaves the rest untouched:

 binarytrees/yklua/15       11319 ± 335   10919 ±  63   0.96  3.54% faster
 HashIds/yklua/6000          9697 ±  79    9377 ± 159   0.97  3.29% faster
 storage/yklua/1000         24632 ± 238   23822 ± 338   0.97  3.29% faster
 cd/yklua/250               33423 ± 176   32825 ± 240   0.98  1.79% faster

The hashids and storage numbers are repeatable. I'm less convinced by the others.

In ykjit#131 I added `yk_outline` to nearly every GC function and got an 8-9%
speedup. Much has changed since then in how we optimise programs, so I
decided to revisit this.

First, as I noted in ykjit#131, I was sloppy and added `yk_outline` to
functions with loops in (i.e. those that could never be inlined). Those
are easily removed. Indeed, _most_ of the static functions in this file
can't be reached (even indirectly) from the outside world, so most of
those can also have `yk_outline` removed.

Really what we have to think about are the `luaC_*` functions. A quick
bit of experimentation suggests that, at least for now, they're best
left outlined.

Overall, this commit has no meaningful performance change that I can
measure.
@vext01 vext01 added this pull request to the merge queue Dec 15, 2025
Merged via the queue into ykjit:main with commit 165e6c3 Dec 15, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants