Skip to content

REF: dont use numexpr in places where it doesnt help. #31984

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

Closed
wants to merge 6 commits into from

Conversation

jbrockmendel
Copy link
Member

DataFrame ops will still use it when dispatching to series/block ops.

Perf neutral:

In [3]: arr = np.arange(10**4).reshape(100, 100)                                                                                                                                    
In [4]: df = pd.DataFrame(arr)                                                                                                                                                      
In [5]: df[4] = df[4].astype(float)                                                                                                                                                 
In [6]: ser = df[0]                     
                                                                                                                                            
In [8]: %timeit res = df+ser                                                                                                                                                        
19.8 ms ± 317 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- PR
19.8 ms ± 267 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- master

In [10]: %timeit res2 = df.add(ser, axis=0)                                                                                                                                         
19.2 ms ± 276 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- PR
19.2 ms ± 301 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- master

In [13]: %timeit res3 = df + df                                                                                                                                                     
23.6 ms ± 382 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- PR
24 ms ± 551 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)  # <-- master

@@ -95,7 +95,10 @@ def run_binary(self, df, other):
expr.get_test_result()
result = op(df, other)
used_numexpr = expr.get_test_result()
assert used_numexpr, "Did not use numexpr as expected."

# We don't currently use numexpr for comparisons in Series,
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm, the original and entire purpose IS to use numexpr for comparisions. I agree consistency is important, but this is turned off for DataFrames? (for regular dtypes)????

Copy link
Member Author

Choose a reason for hiding this comment

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

yah, the right place to do that is in array_ops (which will cause is to do it for Series too)

I've got a branch that implements dataframe-with-dataframe ops block-wise, but the diff for that is pretty big, so im splitting pieces off. the numexpr-for-series-comparisons part will be next

Copy link
Contributor

Choose a reason for hiding this comment

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

ok great

yeah comparison ops should. r a pretty big speedup as it’s parallle
computation

Copy link
Member Author

Choose a reason for hiding this comment

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

ok, im in the process of splitting off the relevant parts of that branch. That may end up affecting the tests here, but the core.ops edits here will be correct regardless.

I think we need to improve the used_numexpr check in the tests to not just check whether numexpr was called, but whether it actually was used effectively

Copy link
Member Author

Choose a reason for hiding this comment

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

also xref #31297 will smooth this out

@jreback jreback added Performance Memory or execution speed performance Reshaping Concat, Merge/Join, Stack/Unstack, Explode labels Feb 16, 2020
@jbrockmendel
Copy link
Member Author

closing in favor of #32047.

@jbrockmendel jbrockmendel deleted the less-expressions branch February 17, 2020 03:31
@jbrockmendel jbrockmendel added the Mothballed Temporarily-closed PR the author plans to return to label Apr 21, 2020
@jbrockmendel jbrockmendel removed the Mothballed Temporarily-closed PR the author plans to return to label Mar 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Performance Memory or execution speed performance Reshaping Concat, Merge/Join, Stack/Unstack, Explode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants