issue_comments

Table actions

7 rows where author_association = "MEMBER" and issue = 521754870 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

user 3

issue 1

  • Should we cache some small properties? · 7 ✖

author_association 1

  • MEMBER · 7 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
553834279 https://github.com/pydata/xarray/issues/3514#issuecomment-553834279 https://api.github.com/repos/pydata/xarray/issues/3514 MDEyOklzc3VlQ29tbWVudDU1MzgzNDI3OQ== crusaderky 6213168 2019-11-14T10:52:13Z 2019-11-14T10:52:13Z MEMBER

python %%prun -s cumulative for _ in range(10000): ds.isel(x=[0]) Output (uncached): ncalls tottime percall cumtime percall filename:lineno(function) 10000 0.148 0.000 3.317 0.000 dataset.py:1854(isel) [...] 60000 0.092 0.000 0.122 0.000 indexing.py:535(shape)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should we cache some small properties? 521754870
553832745 https://github.com/pydata/xarray/issues/3514#issuecomment-553832745 https://api.github.com/repos/pydata/xarray/issues/3514 MDEyOklzc3VlQ29tbWVudDU1MzgzMjc0NQ== crusaderky 6213168 2019-11-14T10:47:43Z 2019-11-14T10:47:43Z MEMBER

I prefer pandas.utils.cache_readonly to the Python 3.8 cachedproperty. Besides not needing a dict, it is also written in cython, which should make a substantial difference.

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.

```python 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@property: 187us With@cache_readonly``: 180us

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should we cache some small properties? 521754870
553815808 https://github.com/pydata/xarray/issues/3514#issuecomment-553815808 https://api.github.com/repos/pydata/xarray/issues/3514 MDEyOklzc3VlQ29tbWVudDU1MzgxNTgwOA== crusaderky 6213168 2019-11-14T10:02:57Z 2019-11-14T10:02:57Z MEMBER

@max-sixty afraid so. But as I said it should be straightforward to use a variant that instead of self.__dict__[self.name] uses getattr/setattr.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should we cache some small properties? 521754870
553573320 https://github.com/pydata/xarray/issues/3514#issuecomment-553573320 https://api.github.com/repos/pydata/xarray/issues/3514 MDEyOklzc3VlQ29tbWVudDU1MzU3MzMyMA== max-sixty 5635139 2019-11-13T19:52:18Z 2019-11-13T19:52:18Z MEMBER

By reading the implementation of cachedproperty, it needs a __dict__. It should be straightforward to write a variant that uses slots though.

Is there a way of doing that which doesn't nullify the benefits of slots? i.e. if we add a _cache_dict to the class, is that the same overhead as having a __dict__?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should we cache some small properties? 521754870
553100094 https://github.com/pydata/xarray/issues/3514#issuecomment-553100094 https://api.github.com/repos/pydata/xarray/issues/3514 MDEyOklzc3VlQ29tbWVudDU1MzEwMDA5NA== crusaderky 6213168 2019-11-12T20:28:45Z 2019-11-12T20:28:45Z MEMBER

By reading the implementation of cachedproperty, it needs a __dict__. It should be straightforward to write a variant that uses slots though. 

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should we cache some small properties? 521754870
553093801 https://github.com/pydata/xarray/issues/3514#issuecomment-553093801 https://api.github.com/repos/pydata/xarray/issues/3514 MDEyOklzc3VlQ29tbWVudDU1MzA5MzgwMQ== max-sixty 5635139 2019-11-12T20:11:22Z 2019-11-12T20:11:35Z MEMBER

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 __slots__, at least without adding an entry to __slots__... https://github.com/python/cpython/blob/d360346640e19231032b072216195484fa2450b4/Lib/functools.py#L954-L958

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should we cache some small properties? 521754870
553079425 https://github.com/pydata/xarray/issues/3514#issuecomment-553079425 https://api.github.com/repos/pydata/xarray/issues/3514 MDEyOklzc3VlQ29tbWVudDU1MzA3OTQyNQ== shoyer 1217238 2019-11-12T19:36:35Z 2019-11-12T19:36:35Z MEMBER

I think this would be totally fine to add. A variant on cache_readonly appears in Python 3.8 standard library as functools.cached_property. I think we could backport that pretty easily: https://github.com/python/cpython/blob/d360346640e19231032b072216195484fa2450b4/Lib/functools.py#L924

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Should we cache some small properties? 521754870

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);