PERF: Slow hdf_read on 10+ million row data + My fix

[daniellevie]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this issue exists on the latest version of pandas.

• I have confirmed this issue exists on the main branch of pandas.

Reproducible Example

import pandas as pd
from time import time
file = "./example_file.h5"
t1 = time()
df = pd.read_hdf(file, "example_data")
t2 = time()
print(t2-t1)

I've noticed that pandas seems to be very slow at reading certain data from a hdf5 file when there are 10s of millions of rows. I frequently work with data that can get into the 100s of millions so this has significantly slowed me down.
I did some digging into the pytables module and found that there is a concat that occurs on line 3221 of the BlockManagerFixed read() method as in the image bellow. By default copy is True so I experimented with setting this to False and noticed an instant 10x performance gain.

I have included a zipped h5 file which you can use to repeat this test. With copy set to False in the concat it loaded for me in less than 2 seconds, otherwise it took over 20 seconds.

I have tested this on Linux, Windows and Mac and get the same level of performance improvement every time.

example_file.zip

Installed Versions

commit : e8093ba
python : 3.8.8.final.0
python-bits : 64
OS : Linux
OS-release : 3.10.0-1062.9.1.el7.x86_64
Version : #1 SMP Fri Dec 6 15:49:49 UTC 2019
machine : x86_64
processor :
byteorder : little
LC_ALL : en_US.UTF-8
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.4.3
numpy : 1.21.5
pytz : 2021.3
dateutil : 2.8.2
setuptools : 61.2.0
pip : 22.1.2
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : 8.4.0
pandas_datareader: None
bs4 : None
bottleneck : 1.3.4
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
markupsafe : None
matplotlib : 3.3.4
numba : None
numexpr : 2.8.1
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : 3.6.1
tabulate : None
xarray : None
xlrd : None
xlwt : None
zstandard : None

Prior Performance

No response

[daniellevie]

Does no one have any opinions on this? Seems like there could be a large performance boost for a good amount of applications.
I've been doing this for the past year and having copy = False has not impacted the results at all for me.

[jreback]

if u put up a pull request someone can look

[phofl]

This does not change anything performance wise on my side

[jbrockmendel]

Removing the copy=True looks completely benign. Go for it.

[jbrockmendel]

I tried removing that copy=True and it breaks pandas/tests/io/pytables/test_store.py::test_hdfstore_strides. That test is specifically checking that strides is preserved in a round-trip, which i don't know how much we care about.