Open ibizaman opened 6 years ago
Magit-status on a repo containing 300 opened PRs took a lot of time. Profiling showed ghubp-host was taking roughly 35%.
This solution uses a hash table to cache the results.
Solves #349 partially.
This PR is not complete, we need a way to refresh the cache
For example, after calling magit-status on this repo, the variable contains:
magit-status
#s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ("/Users/ibizaman/.emacs.d/straight/repos/magithub/" "api.github.com"))
Then after magit-status on the ghub repo:
ghub
#s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ("/Users/ibizaman/.emacs.d/straight/repos/magithub/" "api.github.com" "/Users/ibizaman/.emacs.d/straight/repos/ghub/" "api.github.com"))
Shouldn't this rather be done in ghub+?
ghub+
Magithub can probably refresh the cache inside macro magithub-cache-without-cache. Most (all?) of the 'full refresh' commands get into this codepath eventually.
magithub-cache-without-cache
Magit-status on a repo containing 300 opened PRs took a lot of time. Profiling showed ghubp-host was taking roughly 35%.
This solution uses a hash table to cache the results.
Solves #349 partially.
This PR is not complete, we need a way to refresh the cache
For example, after calling
magit-status
on this repo, the variable contains:Then after
magit-status
on theghub
repo: