-
Notifications
You must be signed in to change notification settings - Fork 444
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
[ti_cif3] Clean up null handling #9148
[ti_cif3] Clean up null handling #9148
Conversation
/test |
5be8fd4
to
48bbb56
Compare
🚀 Benchmarks reportTo see the full report comment with |
@@ -124,13 +124,13 @@ processors: | |||
field: cif3.indicator | |||
target_field: threat.indicator.network.cidr | |||
ignore_missing: true | |||
if: "ctx.threat?.indicator?.type != null && ['ipv4-addr', 'ipv6-addr'].contains(ctx.threat.indicator.type) && (ctx.cif3?.indicator_ipv4_mask != null || ctx.cif3?.indicator_ipv6_mask != null)" | |||
if: "['ipv4-addr', 'ipv6-addr'].contains(ctx.threat?.indicator?.type) && (ctx.cif3?.indicator_ipv4_mask != null || ctx.cif3?.indicator_ipv6_mask != null)" |
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'm wondering if in the cases where the field checks are obviously cheaper, they should not go first to avoid the futile array allocation for the Array.contains
call. The case here and below are clear since it's a null check; the case above with a string compare may be less obvious, but also may benefit since a small string compare should be cheaper than an alloc.
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 did the case above in its own commit.
I did this case and below in a separate commit. These ones I'm ambivalent about because while it makes sense for performance, I think readability is better with the repeated condition first and the differentiating condition following.
💚 Build Succeeded
History
|
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
Package ti_cif3 - 1.10.2 containing this change is available at https://epr.elastic.co/search?package=ti_cif3 |
- Remove redundant null-safe access to ctx. - Make access after null-safe access also be null-safe. - Combine 'not null and is/not value' checks.
Proposed commit message
Checklist
changelog.yml
file.Related issues
null
handling inif
conditions and elsewhere #8646