Skip to content
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

Improve performance of bypassing #623

Merged
merged 1 commit into from
Jan 11, 2018
Merged

Conversation

DNNX
Copy link
Contributor

@DNNX DNNX commented Jan 10, 2018

It makes sense to short-circuit Chewy's update_proc when current strategy is bypass.

Currently, even when current strategy is to bypass ES, Chewy still takes time to evaluate the backreference (which is an AR relation, usually).

It's better to skip it as it affects the performance of an application.

Why not put next if ... in the beginning of the proc?

Because Chewy.derive_type may cause some chewy types to load, if Rails' eager_load is false. If we stop calling Chewy.derive_type, this can cause undesired behavior and bugs, which actually happened in one of the applications I work on. So, in order to preserve existing behavior, we call derive_type before next if, and the remaining part after the next if .... The remaining part is the heaviest one performance-wise, anyway.

It makes sense to short-circuit Chewy's
`update_proc` when current strategy is `bypass`.

Currently, even when current strategy is to bypass ES,
Chewy still takes time to evaluate the backreference
(which is AR relation, usually).

It's better to skip it as it affects performance of the
application.

Why not put `next if ...` in the beginning of the proc?

Because `Chewy.derive_type` may cause some chewy types to
load, if Rails' `eager_load` is `false`. This can cause
undesired behavior and bugs. So, in order to preserve
existing behavior, we call `derive_type` _before_ `next if`,
and the remaining part after the `next if ...`. The remaining
part is the heaviest one performance-wise, anyway.
@DNNX DNNX self-assigned this Jan 10, 2018
@DNNX DNNX requested a review from pyromaniac January 10, 2018 12:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants