-
Notifications
You must be signed in to change notification settings - Fork 24.9k
Use native implementation of equals in ReadableNativeArray #52611
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
Conversation
This pull request was exported from Phabricator. Differential Revision: D78340288 |
This pull request was exported from Phabricator. Differential Revision: D78340288 |
…52611) Summary: Pull Request resolved: facebook#52611 We compare the current transform (represented as a ReadableArray) with the incoming one to know whether to invalidate. This can be expensive as it requires to materialize the entire transform data structure over JNI. Instead, we can delegate this comparison to native code, which can compare the underlying folly::dynamic directly. Changelog: [Internal] Differential Revision: D78340288
4a4086a
to
4b5a47e
Compare
…52611) Summary: Pull Request resolved: facebook#52611 We compare the current transform (represented as a ReadableArray) with the incoming one to know whether to invalidate. This can be expensive as it requires to materialize the entire transform data structure over JNI. Instead, we can delegate this comparison to native code, which can compare the underlying folly::dynamic directly. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D78340288
This pull request was exported from Phabricator. Differential Revision: D78340288 |
4b5a47e
to
ca92aeb
Compare
This pull request has been merged in 5d3d23b. |
This pull request was successfully merged by @javache in 5d3d23b When will my fix make it into a release? | How to file a pick request? |
…52611) Summary: Pull Request resolved: facebook#52611 We compare the current transform (represented as a ReadableArray) with the incoming one to know whether to invalidate. This can be expensive as it requires to materialize the entire transform data structure over JNI. Instead, we can delegate this comparison to native code, which can compare the underlying folly::dynamic directly. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D78340288 fbshipit-source-id: f44a054e234694c316fb080fe2dbc2017780123a
Summary: Pull Request resolved: #52611 We compare the current transform (represented as a ReadableArray) with the incoming one to know whether to invalidate. This can be expensive as it requires to materialize the entire transform data structure over JNI. Instead, we can delegate this comparison to native code, which can compare the underlying folly::dynamic directly. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D78340288 fbshipit-source-id: f44a054e234694c316fb080fe2dbc2017780123a
This pull request was successfully merged by @javache in 1b5c183 When will my fix make it into a release? | How to file a pick request? |
…eNativeTransformHelperAndroid` in the experimental channel (#53567) * Use native implementation of equals in ReadableNativeArray (#52611) Summary: Pull Request resolved: #52611 We compare the current transform (represented as a ReadableArray) with the incoming one to know whether to invalidate. This can be expensive as it requires to materialize the entire transform data structure over JNI. Instead, we can delegate this comparison to native code, which can compare the underlying folly::dynamic directly. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D78340288 fbshipit-source-id: f44a054e234694c316fb080fe2dbc2017780123a * Use native helpers to accelerate transform processing (#52603) Summary: Pull Request resolved: #52603 Processing transforms is expensive in Java, as it requires bridging the entire ReadableNativeArray/Map. Instead, we can use the existing parser logic `resolveTransform` logic to perform this operation in C++. Ideally, we actually re-use the existing parsed transform from Props, that could be something we revisit after Props 2.0. As a follow-up, we should consider also moving the matrix decomposition logic from MatrixMathHelper here, and make that the only information we send back to Java. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D78298588 fbshipit-source-id: a698ac8587ccfb2be04665747082398ccdde9294 * Add TransformHelper.cpp to `reactnativejni_common` (#52640) Summary: Pull Request resolved: #52640 Not having `TransformHelper.cpp` included in CMake is causing the C++ code to fail compiling. This diff fixes it. Changelog: [Internal] [Changed] - Reviewed By: cipolleschi, javache Differential Revision: D78414015 fbshipit-source-id: 4900427a86eb38bfec10e5e385296d89c73e9051 * [LOCAL] Unbreak compilation due to CMake dependencies --------- Co-authored-by: Pieter De Baets <pieterdb@meta.com>
This pull request was successfully merged by @cortinico in a346096 When will my fix make it into a release? | How to file a pick request? |
Summary:
We compare the current transform (represented as a ReadableArray) with the incoming one to know whether to invalidate. This can be expensive as it requires to materialize the entire transform data structure over JNI. Instead, we can delegate this comparison to native code, which can compare the underlying folly::dynamic directly.
Changelog: [Internal]
Differential Revision: D78340288