-
Notifications
You must be signed in to change notification settings - Fork 7
[WIP] Refactor symbol generation and LookupProvider registration logic #53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[WIP] Refactor symbol generation and LookupProvider registration logic #53
Conversation
|
Before going with this pr, I recommend discussing the structure and goals(?). |
Thank you for your comments. |
0191ffe to
69cd3c1
Compare
5c24a05 to
86f9457
Compare
JSUYA
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there's a need to separate symbols.dart anymore.
I think a single generated_symbols.dart file, like before, should be sufficient.
And since the ultimate key point is the _lookupProvider.registerSymbols() call, it seems more efficient to internally manage the list of symbols registered rather than generating all tizen{Modulename} instances. Then, it seems like calls can be made in the existing tizen.{api} format.
What do you think?
This PR introduces the following changes to reduce the loading time of the first API call.
symgento generate separate symbol files for each target library.LookupProviderto enable dynamic symbol registration viaregisterSymbolsmethod.Tizen_interop api's loading time was improved by approximately 88% after this change was applied.