This server has felt a bit slow recently and I caught some real silly stuff in profiles, so I'm going to see how much I can clean up.
Description
Revisions and Commits
rPHU libphutil | |||
D13323 | rPHU81eed10bea57 Make loading library maps much cheaper | ||
rP Phabricator | |||
D13325 | rPb3ae48d8ca2d Improve Differential query plans | ||
D13324 | rP984976ce2029 Cache viewer spaces | ||
D13322 | rP6933ee5fb86d Don't spend ridiculous amounts of time rebuilding orderable columns | ||
D13321 | rP8484adcffdf6 Cache application visibility in the request cache |
Related Objects
- Mentioned In
- T8631: Straighten out the fetch plan for feed stories
- Mentioned Here
- D10600: Implement a git blame cache
Event Timeline
Feed is doing some pretty silly stuff where it loads transactions, then loads their objects, then loads their handles (which loads their objects again), then loads the objects, then loads handles, which loads the objects again. In some cases, this loads objects about 6x more often than necessary. However, I think this is mostly specific to Feed, and it's not trivial to disentangle. I may take another look tomorrow.
I'm a reviewer of so many revisions on this install that Differential looks at doing a 13K row table scan of revision or a 15K row join from edge and picks the scan. If there was a key on with status as the first component, it could examine 408 rows instead. This is probably not common in the wild, but maybe worth adding.
Maybe take a look @ D10600: Implement a git blame cache
Enabling blame on a file like:
https://secure.phabricator.com/diffusion/P/browse/master/src/__phutil_library_map__.php
is quite a good benchmack ;)
My diff might be a bit outdated though and i think it's biggest performance gain was by using PHID's to render the blamed commits in the Controller instead of the identifiers.
I think I got all the incredibly dumb, incredibly easy stuff. Plenty of room left, but this install is feeling responsive to me again.
I'm probably going to move this host to newer hardware at some point soon-ish, too (this VM is almost 2.5 years old) but I want to wait for more of a lull in the development cycle.