Skip to content

Browser ext perf issue when "Experimental text field completion" is enabled

Created by: sqs

Note: This ONLY affects users who have enabled the "Experimental text field completion" feature flag in the browser extension options menu. This is not high priority because this is an internal-only feature flag.

@lguychard I am debugging a perf issue in the extensions code. We are performing many more updates than before (w/o the feature flag enabled): eg each time the user types a key into a GitHub textarea, it updates the model content so that completion providers can read it.

Each keypress generates about 934 messages, which generates a LOT of garbage that needs to be collected.

To repro this locally:

  1. Set a logpoint or add console.count to https://sourcegraph.com/github.com/sourcegraph/sourcegraph@13cdf16ce3cdad5aa039bc97b58d3b355d43ce8d/-/blob/client/browser/src/platform/extensionHost.ts#L60:17
  2. Enable the "Experimental text field completion" feature flag
  3. Go to a textarea like the one at https://github.com/sourcegraph/sourcegraph/issues/new
  4. Press a key
  5. See that around 934 messages are received

To repro the problem, hold down the a key. It usually starts to cause significant GC pauses after about 100 characters are added to the textarea.

I am going to push an improvement to the throttling that significantly helps with the problem, but the best improvement is to reduce the number of messages sent via Comlink.

  • https://github.com/GoogleChromeLabs/comlink/pull/242#issuecomment-471307236 suggests that Comlink v4 may create less garbage. Can we try upgrading?
  • We should figure out how to reduce the number of messages. Any quick ideas for improvement off the top of your head?
  • Note that the slowness/GC problem doesn't seem to occur on the web app. My hypothesis is that chromePortListener is worse about transferring objects without de/serialization than the Web Worker channel. Does that seem right?