-
-
Notifications
You must be signed in to change notification settings - Fork 1k
[General] Schedule flushes instead of flushing immediately #3830
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
| currentGestureRef.current = { type, tag }; | ||
| RNGestureHandlerModule.createGestureHandler(type, tag, {}); | ||
| RNGestureHandlerModule.flushOperations(); | ||
| // It's possible that this can cause errors about handler not being created when attemting to mound NativeDetector |
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.
| // It's possible that this can cause errors about handler not being created when attemting to mound NativeDetector | |
| // It's possible that this can cause errors about handler not being created when attempting to mount NativeDetector |
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.
Also, isn't it connected with the error that I've shown you offline? The one when app would sometimes crash on startup because handler has not yet been created?
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 know - it cannot be the cause, since it wasn't there when you found it, but I also was able to reproduce that only by modifying RNGH source while the app was running.
Co-authored-by: Michał Bert <63123542+m-bert@users.noreply.github.com>
## Description This takes things a step further than #3830. By wrapping every call to the native module (from V3) with `NativeProxy`, we have a centralized place that communication with the module always goes through. Using that, most needed operations are batched. The exceptions are `updateGestureHandlerConfig` (see comment) and `createGestureHandler`, which needs to run synchronously. This should reduce the amount of unnecessary native calls. On web, "everything is native" so no batching there. We may investigate the potential gains in the future, but due to differences in scheduling the same approach as on Android/iOS won't work. I've also changed `createGestureHandler` on iOS to create the `UIGestureRecognizer` immediately. This solved a weird "double free" crash I've been seeing. ## Test plan Tested on the same code as #3830 I saw improvements from ~600ms to ~595ms
Description
Currently, when creating a gesture or configuring relations,
flushOperationsis called immediately. When rendering multiple detectors in the same batch, this adds unnecessary overhead as it can be done a single time at the end of the batch. This PR changes that.I also noticed that
createGestureHandleris scheduled on the UI anyway, so I figured there may be no point in keeping it synchronous.Test plan
Used this stress test to measure impact:
I saw the average time fall from ~610ms to ~595ms.