[Performance] Lots of timers installed and cleared

[josephliccini]

Hi,

I have a SessionID: ca3082a6-2a97-4699-9add-eda17ad3b702
And a profile that goes with it: https://microsoft-my.sharepoint-df.com/:u:/p/joliccin/EX1bkObepNRKkRquZ9DsoCgBwUSiPAxCXkwSwlA75IDWeA?e=5TsSYQ

In the profile, I'm interested in the 9000ms to 10000ms part (not the Scriptor stuff before that, I have already talked to Frankie about that)

I am seeing that Fluid is running some heursitic that says "Should I take a snapshot?", and it seems to be installing and clearing timers frequently. Since this is a browser API, it's not the most efficient thing to do in high frequency.

This is the function, in officeFluidContainer.js

handleOp(e, t) {
    void 0 === e && (this.heuristics.lastOpSeqNumber = t.sequenceNumber,
    t.type === d.a.Save ? this.trySummarize(`;${t.clientId}: ${t.contents}`) : this.heuristics.run())
}

Here's what it looks like zoomed in:

a little zoomed out:

a little more:

It's not the biggest bottleneck here in isolation, but if you don't need to install as many timers, you may be able to save a good amount of time in aggregate, especially on slower devices.

[tylerbutler]

I think the source function is in packages\runtime\container-runtime\src\summarizer.ts, the handleOp method. @arinwt @vladsud - FYI

[vladsud]

Thanks for bringing it up! Yes, I think we need to address it.
I have faced similar problem in native world (where rich office client attempt to measure responsiveness through setting and resetting timer on each message) was killing scalability of office on terminal server.
We addressed it twofold - as an optimization in Windows itself, but also in Office through an abstraction over timers that was not cancelling timer (and reusing it later) right away if if was too far out and the cost of firing unneeded timer (battery, scalability) was not high enough compared to potential gain of not continuously cancelling and rescheduling a timer.

[vladsud]

@arinwt, is this already addressed? That's an old bug, and I believe we no longer have issues with timers here, but worth confirming.

[arinwt]

I did address the excessive restarts within summarizer code using restart() in #770, so yes I think we can close this. There may be other places in our code that aren't using the optimized restart function, but it would only matter if they are excessive.