◀ Merged tasks: T5573.

T6088 is an example of this disrupting things in the wild, rather than just being a performance issue. It can also help with T5834.

• We have a large number of callsites where code executes a TransactionQuery and then builds a TransactionView. Pull this somewhere common (maybe PhabricatorControler or somewhere in ApplicationTransactions) with some signature like buildTransactionTimeline($viewer, $object, new WhateverQuery(), new WhateverView()).
• This will generally clean things up, and incidentally make T5834 easier to implement by letting us add needTokens(true) in one place.
• Instead of loading all transactions, use a pager to load the 100 most recent (for whatever value of 100 feels good).
• Pass the pager to the transaction view and have it render a "this thread is very long. Show older changes" kind of thing.
• Some new endpoint in Transactions ajaxes things in 100 at a time.
• The "changes from before the last time you commented" thing interacts with this. It might be nice to combine them:
  • After loading the first page, apply the "hide transactions before your last comment" filter.
  • Only render what isn't filtered out.
  • Start the ajaxing pager at the first hidden transaction.
  • A single new endpoint serves both use cases.
  • If you've never commented, we kick in at 100 transactions.

There's probably some optimization opportunity in the rendering pipeline too, but the cost on T603 isn't wildly unreasonable (~5ms per transaction) so we probably can't easily make it like 10x faster.

Support Impact Disruptive in the wild and unscalable.