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

Optimize out empty ifs #9314

Closed

Conversation

ycombinator
Copy link
Contributor

@ycombinator ycombinator commented Apr 2, 2018

Resolves #9301.

If an if statement has no true or false sub-statements, there is no point including the if statement in the LIR graph. So instead of constructing a sub-graph for the if statement — which would include an empty if vertex and nothing else — and returning it, we return an empty graph object.

If an if statement has no true or false sub-statements, there is no point including the if statement in the LIR graph. So instead of constructing a sub-graph for the if statement — which would include an empty if vertex and nothing else — and returning it, we return an empty graph object.
@ycombinator
Copy link
Contributor Author

ycombinator commented Apr 2, 2018

@andrewvc I realize this implementation isn't exactly what you had in mind (i.e. to create an optimize() method on Graph that would optimize away empty ifs).

My thinking behind the implementation in this PR was: why create empty ifs in the graph at all if we can detect them when converting from imperative -> IR? This way users could still specify empty ifs in their imperative config but we'd optimize them away when creating the graph. When it comes to allowing users to build the graph directly (via a pipeline builder UI, for example), we could check for empty ifs and prevent users from creating them.

Thoughts?

@original-brownbear
Copy link
Member

@andrewvc for what it's worth, I'm with @ycombinator here. The Graph already is a sort of reordered version of the imperative code => I think it's fine to interpret removing redundant statements as being in the same category of reordering and just optimizing them out without ever hitting the Graph :)

@original-brownbear
Copy link
Member

LGTM btw :)

@andrewvc
Copy link
Contributor

andrewvc commented Apr 3, 2018

I'm OK with this approach for now since this is our only optimization.

I do think that this is not, however, scale-able if we add additional frontends. However, this is a relatively simple optimization, and it's literally our only real one at this point, so I'm OK with it.

Copy link
Contributor

@andrewvc andrewvc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM. Great work :)

Could use some more tests. Those tests should probably have already existed before this PR. However, this feels like a good place to put the campsite rule (leave the code better than you found it) into effect, and round out the IfStatement tests.

public class IfStatementTest {

@Test
public void testEmptyIfStatement() throws InvalidIRException {
Copy link
Contributor

@andrewvc andrewvc Apr 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize that this file didn't exist previously. We primarily tested this path through other means.

That said, this feels a bit incomplete with only the test for the new case we've added.

Would you mind adding one more test for the case where the if statement does have non-noop paths?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem at all, happy to add more tests here!

@ycombinator
Copy link
Contributor Author

@andrewvc I've added more unit tests for IfStatement in a6c52fc. This PR is ready for re-review.

@andrewvc
Copy link
Contributor

andrewvc commented Apr 3, 2018

Thanks for adding the comprehensive tests! I apologize if this is too nitpicky, but I do think these tests could be more concise / more accurate. I opened ycombinator#1 to show how you might do that for one of the tests.

The nice thing about this approach is that since it diffs the whole graph it's a more comprehensive test than just counting things.

It's also shorter to boot.

Refactor test to use graph equality check for conciseness / accuracy
@ycombinator
Copy link
Contributor Author

@andrewvc Merged your PR and updated the rest of the unit tests to use the same pattern. Ready for review again. Thanks!

Copy link
Contributor

@andrewvc andrewvc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Congrats on your first PR to Logstash Core @ycombinator ! 🎊

@elasticsearch-bot
Copy link

Shaunak Kashyap merged this into the following branches!

Branch Commits
master 9859ec2, e66ac21, 2e69f1c, ec3e8be, cf16429, f1b6d7c
6.x 60ae51e, d5c9d33, def8742, 94d8ee3, cbfb47c, 376cb02

elasticsearch-bot pushed a commit that referenced this pull request Apr 4, 2018
elasticsearch-bot pushed a commit that referenced this pull request Apr 4, 2018
elasticsearch-bot pushed a commit that referenced this pull request Apr 4, 2018
elasticsearch-bot pushed a commit that referenced this pull request Apr 4, 2018
If an if statement has no true or false sub-statements, there is no point including the if statement in the LIR graph. So instead of constructing a sub-graph for the if statement — which would include an empty if vertex and nothing else — and returning it, we return an empty graph object.

Fixes #9314
elasticsearch-bot pushed a commit that referenced this pull request Apr 4, 2018
elasticsearch-bot pushed a commit that referenced this pull request Apr 4, 2018
elasticsearch-bot pushed a commit that referenced this pull request Apr 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants