I don't think it can be cached, or at least not very effectively; the result depends on the current time (for the relative time display), and also on the user viewing it (for the state of topic subscriptions and presence of thanks buttons). A whole second is a lot slower than I would expect it to be though, even on large pages; I recorded a profile and there are some possible improvements.
Here's the profile: https://performance.wikimedia.org/excimer/profile/56e998919df45ca2, and screenshot zoomed into the DiscussionTools OutputPageBeforeHTML hook handler in case that page disappears:
It indeed took a bit over a second. Two things strike me:
- There is a separate HtmlHelper::modifyElements() pass inside postprocessTopicSubscription(). In commit 37856941cffb646067c3df1a7ef639ffe65a475c we've combined all other postprocessing into a single HtmlHelper::modifyElements() pass, but this one has to be done separately, since it prepares data for a single SQL query that fetches topic subscriptions status for every topic on the page. We don't use the output from this pass – maybe something can be done to reduce the overhead.
- Inside the other HtmlHelper::modifyElements() pass, there are some very deep stack traces, which turn out to be parsing localisation messages repeatedly. I looked at the code and we already cache them in some places (e.g. 'discussiontools-replybutton' is only parsed once and then cached), but not others (e.g. 'thanks-button-thank').