Update mrbind: table-driven Python bindings registration - #6574
Open
Fedr wants to merge 3 commits into
Open
Conversation
Picks up the mrbind change that registers bound methods, fields and enum elements from constexpr data tables instead of per-entity template instantiation chains, which shrinks mrmeshpy substantially.
The previous commit pointed at a commit that does not exist.
Static member functions no longer carry the class type into the registrar shape, so they can share registrars with equally-shaped free functions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the
thirdparty/mrbindgitlink to pick up mrbind#44, which registers bound methods, fields and enum elements fromconstexprdata tables instead of one straight-line chain of template instantiations per entity. That long tail of near-duplicate instantiations is what dominates the size ofmrmeshpy.This replaces #6544, which was based on the withdrawn mrbind#42. That version replicated pybind11 internals; this one reimplements nothing from pybind11 and needs no change to our pybind11 fork.
Wheel A/B
Same MeshLib commit (4e5f11f),
publish=dry, macOS and Windows disabled. Baseline run 31465130784, this branch 31465420437. Both fully green, including all 14manylinux-pip-testlegs (Python 3.8-3.14 x both arches).mrmeshpy.socompressed (in wheel)mrmeshpy.so.textmrmeshpy.sounpackedmeshlib-corewheelmrmeshpy.socompressed (in wheel)mrmeshpy.so.textmrmeshpy.sounpackedmeshlib-corewheelmrmeshpy.pyiis byte-identical on both arches (107,927 / 107,924 lines), so nothing about the generated API changes.mrcudapy.soshrinks too (-6.0% / -5.1% compressed) since it's generated as well, andmrmeshnumpy.sois unchanged to the byte, as expected for hand-written bindings.The only
.pyidifference anywhere is one import line at a different position inmrcudapy.pyi. That's the known pre-existing registration-order nondeterminism (type_entriesis pointer-hash ordered, so two builds of pure master differ the same way), not something this bump introduces.The "Generate and build MRBind bindings" step also got a bit faster: 17m36s -> 15m35s on x86_64, 11m11s -> 10m14s on aarch64.
Re-point the gitlink at the squashed mrbind master commit before merging, and squash the fixup commits on this branch.