feat: add generic model loading#395
Merged
JakubGonera merged 2 commits intomainfrom Jun 13, 2025
Merged
Conversation
mkopcins
approved these changes
Jun 13, 2025
mkopcins
pushed a commit
that referenced
this pull request
Oct 15, 2025
## Description In `RnExecutorchInstaller` we can use `loadModel<T>` to install to JSI a method that will load our model without writing the same code for each module. The problem is that this method expects that each module needs exactly a string and a CallInvoker in the constructor, which restricts usage of the method for modules which would have multiple sources or other arguments (e.g. OCR or encoder/decoder modules). At the same time, even if modules have different input on load, the code would look nearly identical, so a generic solution is needed for this case. This PR allows for generic loading of modules if the type info about the constructor is supplied by `REGISTER_CONSTRUCTOR` macro. This allows for a generic conversion of arguments from JSI, similar to `ModelHostObject`. The machinery required for this (`ConstructorHelpers.h`) is admittedly more complicated than in the case of `ModelHostObject` due to the fact that we need to specify the types ourselves (we cannot grab method pointers to constructors to infer the types), and due to having `CallInvoker` as the last argument. ### Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] Documentation update (improves or adds clarity to existing documentation) ### Tested on - [x] iOS - [x] Android ### Related issues #255 ### Checklist - [x] I have performed a self-review of my code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have updated the documentation accordingly - [x] My changes generate no new warnings
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
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.
Description
In
RnExecutorchInstallerwe can useloadModel<T>to install to JSI a method that will load our model without writing the same code for each module. The problem is that this method expects that each module needs exactly a string and a CallInvoker in the constructor, which restricts usage of the method for modules which would have multiple sources or other arguments (e.g. OCR or encoder/decoder modules). At the same time, even if modules have different input on load, the code would look nearly identical, so a generic solution is needed for this case.This PR allows for generic loading of modules if the type info about the constructor is supplied by
REGISTER_CONSTRUCTORmacro. This allows for a generic conversion of arguments from JSI, similar toModelHostObject. The machinery required for this (ConstructorHelpers.h) is admittedly more complicated than in the case ofModelHostObjectdue to the fact that we need to specify the types ourselves (we cannot grab method pointers to constructors to infer the types), and due to havingCallInvokeras the last argument.Type of change
Tested on
Related issues
#255
Checklist