lemon24
commented
1 year ago OK, some timings taken with reader._plugins.timer (all times in seconds):
| render | reader | methods | |
|---|---|---|---|
| /feeds | .20 | .06 | .01 get_feeds, .05 get_tag_keys (N calls) |
| /feeds?sort=unread | .46 | .31 | .01 get_feeds, .05 get_tag_keys, .25 get_entry_counts (N calls) |
| /?limit=180 | .26 | .12 | .06 get_entries, .09 get_tag (readtime plugin) |
| /?q=python&limit=180 | .75 | .59 | .32 search_entries, .09 get_tag, .18 get_entries (N calls) |
Some thoughts/conclusions:
- The web app adds a constant ~.15s overhead for similar-sized pages.
- Batch methods may help with getting the tags in the same get_feeds() / get_entries() query. Same for getting the entry in search_entries().
- However, I'm not sure they can help with get_entry_counts() (each sub-query still has to count the same different sets of entries as the individual calls).
- Caching may be a better idea here; but, to sort natively, we have to add either a cached counts column, or "sort by arbitrary tag / tag field" if we use tags (like we do with readtime). The latter would also open the door to efficiently sorting entries by read time.
2024-08 update: Have a look at https://sqlite-utils.datasette.io/en/stable/python-api.html#python-api-cached-table-counts for more ideas on caching.
(originally titled /feeds is slow)
On my deployment, for 180 feeds, /feeds renders in (after repeated refreshes):
For comparison:
Is this the library or the app?