Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instrument accepted suggestion contributions #136922

Merged
merged 6 commits into from
Nov 12, 2021

Conversation

JacksonKearl
Copy link
Contributor

Adding some telemetry to get a better understanding of what extensions produce helpful suggestions in a given context (language /file extension/ (hashed) file name).

@JacksonKearl JacksonKearl self-assigned this Nov 11, 2021
@JacksonKearl
Copy link
Contributor Author

Put in the finally to hopefully eliminate any possible perf impact on the core snippet insertion routine, let me know what you think.

Copy link
Member

@jrieken jrieken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good so far but we should consolidate _debugDisplayName and _source because the former is kinda serving the same purpose

/**
* @internal
*/
_source?: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This basically duplicates _debugDisplayName but looses precision. Extensions like TypeScript register a couple of completion item providers (I believe 3 for JS and 3 for TS) and the debug display name allows you to tell them apart (with some chance of error). Like, you won't be able to differentiate the accept rate of JSDoc completions vs semantic completions etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, so I had originally kept them separate because the snippet provider's source could be more specific than the current display name. But given that's not actually happening yet I agree this is not needed.


const resourceLoggedEvents = this._loggedEvents.get(model.uri) ?? new Set<string>();
if (!this._loggedEvents.has(model.uri)) {
this._loggedEvents.set(model.uri, resourceLoggedEvents);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is never being cleared so a potential, slow memory leak. It's also not clear why we gate the telemetry? You won't be able to say anything about the frequency of provider-usage because a single usage is enough, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi - to reduce telemetry load (in case that's the intention here) I have used this pattern in the past:

private _telemetryGate: number = 0;
. Basically only report telemetry every so many times

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to reduce cycles that don't immediately benefit the user in the core edit loop as much as possible, the modulo-gating strategy makes good sense.


const providerId = event.item.provider._source ?? event.item.provider._debugDisplayName ?? 'unknownProvider';
if (!resourceLoggedEvents.has(providerId)) {
resourceLoggedEvents.add(providerId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion to extract this into a separate function, similar to this. Maybe also wrapped in a setTimeout or idleCallback to ensure this doesn't impact editor rendering perf (which seems unlikely)

Copy link
Member

@jrieken jrieken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢 it

Copy link

@raghavthind2005 raghavthind2005 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks good to me too!

@JacksonKearl JacksonKearl merged commit 694097a into main Nov 12, 2021
@JacksonKearl JacksonKearl deleted the jackson/accepted-suggestion-instrumentation branch November 12, 2021 18:40
@github-actions github-actions bot locked and limited conversation to collaborators Dec 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants