possible to remove unused parts of Lua from the compiled binary?

[naturallymitchell]

@kyren, thx for driving forward jazzdotdev/jazz#259. hopefully someone will find that regression soon if there is one.

perhaps we could find it from this angle too, more easily even, since we only need ~20% of Lua's codebase and "The Best Code is No Code At All", (also discussed in jazzdotdev/jazz#262)

[kyren]

Hmmm, in order to remove them from the binary, it would involve patching the Lua source.

You can now choose which std libraries to load on startup and just not load io, math, etc. Is it extremely important that they not be included in the binary? Won't the linker potentially strip it out if it's completely unused?

[naturallymitchell]

it would involve patching the Lua source

that's what I expected, and/or making cfg features in rlua. how does that seem to you? having a "slim-lua" would make sense to me.

Is it extremely important that they not be included in the binary?

no, it isn't. in the debug library's case, for example, we just don't expose it, and that accomplishes my main interest inline with your safety precautions. I'm guessing that'll also work for that issue, but I still need feedback to firm up that plan.

Won't the linker potentially strip it out if it's completely unused?

I haven't looked into that before, so idk. if it does, would that improve performance? (that's my targeted side benefit and the main reason for this issue.)

[naturallymitchell]

You can now choose which std libraries to load on startup and just not load io, math, etc.

oh, yea. 68b90e7 looks really good.

[kyren]

I haven't looked into that before, so idk. if it does, would that improve performance?

Not really, except some minor startup performance. If you've seen a huge regression, I suspect that something else is going on, and if it's a HUGE regression then that's good because it's hopefully dumb and easy to fix.

[naturallymitchell]

how can we go about finding it? would jazzdotdev/jazz#125 help? or these profiling and debugging Rust tools?

[kyren]

You don't need rust specific tools to find performance problems, generic tools will often do the job just fine.

I would start with perf on linux or Instruments.app on MacOS. I can help if you'd like, if you can give me some git hashes and instructions on how to demonstrate the difference.

[jugglerchris]

Closing as I don't think we would want to patch Lua to remove parts of it in rlua.

@naturallymitchell If you still have a performance issue please feel free to open an issue with some details to allow us to reproduce it or narrow down where or when it is. (Apologies if you have already done this and I haven't got to that issue yet!)