-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Should we cache some small properties? #3514
Comments
I think this would be totally fine to add. A variant on |
Great, I didn't know about that, thanks It does remind me, though, that I'm not sure it's possible given we're using |
By reading the implementation of cachedproperty, it needs a |
Is there a way of doing that which doesn't nullify the benefits of slots? i.e. if we add a |
@max-sixty afraid so. But as I said it should be straightforward to use a variant that instead of |
I prefer max-sixty could you post your benchmark where you measure 150us? I tried caching that property with @cache_readonly and I only get a boost of 7us. import xarray
ds = xarray.Dataset({'d': ('x', [1, 2]), 'x': [10, 20]})
ds
ds.to_netcdf("foo.nc")
ds.close()
ds = xarray.open_dataset("foo.nc")
%timeit ds.isel(x=[0]) With |
%%prun -s cumulative
for _ in range(10000):
ds.isel(x=[0]) Output (uncached):
|
I was doing some profiling on
isel
, and see there are some properties that (I think) never change, but are called frequently. Should we cache these on their object?Pandas uses cache_readonly for these cases.
Here's a case: we call
LazilyOuterIndexedArray.shape
frequently when doing a simple indexing operation. Each call takes ~150µs. An attribute lookup on a python object takes ~50ns (i.e. 3000x faster). IIUC the result on that property should never change.I don't think this is the solution to performance issues, and there's some additional complexity.
Could they be easy & small wins, though?
The text was updated successfully, but these errors were encountered: