BUG: Subsequent calls to df.sub() are much faster than the first call #34297
Labels
MultiIndex
Numeric Operations
Arithmetic, Comparison, and Logical operations
Performance
Memory or execution speed performance
Milestone
Comments
philippegr
added
Bug
Needs Triage
|
Is it from allocating the hashtable for the index(es)? Can you profile the first and subsequent calls with snakeviz and see what differs? |
|
Output of %prun for first call |
|
And for the second call |
|
So, in more graphical view, this is what comes inside |
|
This definitely has something to do with # Before running any of the sub command in the first code snippet
# Changing index type of ref to category
ref_df.index = ref_df.index.astype('category')
# %%time about 150 ms, output is MultiIndexed (str, datetime)
res_1 = value_df.sub(ref_df, level=0)
# Changing index back to str and ensuring result is the same
ref_df.index = ref_df.index.astype('str')
res_2 = value_df.sub(ref_df, level=0)
assert pd.DataFrame.equals(res_1, res_2) |
|
Looks like there is some low-hanging fruit in MultIIndex.equals, since it is going through Its the |
Is that what gets computed (cached?) upon first call (hence the delay) and thus why it is faster afterwards? |
jreback
added
MultiIndex
Numeric Operations
|
Thank you very much, looking forward to 1.1! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of pandas.
(optional) I have confirmed this bug exists on the master branch of pandas.
Code Sample, a copy-pastable example
Problem description
There is a significant difference in speed between the first and second call to
sub(which are the same instruction) in the code above. I don't understand where this is coming from. In particular why this is notably slower than merge (whose performance remains consistent).Upon investigation, I noticed that the difference between runs is much smaller if value_df.index.level[0] is of type int (80ms for the first run 60ms for the subsequent)
Expected Output
Current output is correct, speed of first call is the issue here
Output of
pd.show_versions()INSTALLED VERSIONS
commit : None
python : 3.7.7.final.0
python-bits : 64
OS : Darwin
OS-release : 18.7.0
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : en_CA.UTF-8
LOCALE : en_CA.UTF-8
pandas : 1.0.3
numpy : 1.18.1
pytz : 2020.1
dateutil : 2.8.1
pip : 20.0.2
setuptools : 46.4.0.post20200518
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.11.2
IPython : 7.13.0
pandas_datareader: None
bs4 : None
bottleneck : None
fastparquet : None
gcsfs : None
lxml.etree : None
matplotlib : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pytables : None
pytest : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
xlsxwriter : None
numba : None
The text was updated successfully, but these errors were encountered: