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

Switch to value-tasks in a few oop syncing points. #63056

Merged
merged 6 commits into from
Jul 29, 2022

Conversation

CyrusNajmabadi
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi commented Jul 29, 2022

Noticed while profiling this area.

I recommend reviewing one commit at a time.

{
Debug.Assert(!checksums.Contains(Checksum.Null));
if (checksums.Count == 0)
return;
Copy link
Member Author

Choose a reason for hiding this comment

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

this is a core change/thing i noticed. When logging this information. we call into this tons of times with nothing to actually sync. Roughly 98%+ of the time this happens. so this can insta-bail. Which allows this to sensibly be a value task. the rest is just bubbling that upwards for all calls that themselves are just calling awaiting value-task helpers.

@@ -52,24 +52,22 @@ public override async Task<T> GetAssetAsync<T>(Checksum checksum, CancellationTo
}
}

public async Task<List<ValueTuple<Checksum, T>>> GetAssetsAsync<T>(IEnumerable<Checksum> checksums, CancellationToken cancellationToken)
public async ValueTask<ImmutableArray<ValueTuple<Checksum, T>>> GetAssetsAsync<T>(HashSet<Checksum> checksums, CancellationToken cancellationToken)
Copy link
Member Author

Choose a reason for hiding this comment

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

passing items with known length allows us to optimize more (both by bailing out early and by getting the right sized immutable collections to return).

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we use an Immutable type here?

@CyrusNajmabadi CyrusNajmabadi marked this pull request as ready for review July 29, 2022 17:49
@CyrusNajmabadi CyrusNajmabadi requested review from a team as code owners July 29, 2022 17:49
@CyrusNajmabadi CyrusNajmabadi requested a review from dibarbet July 29, 2022 17:49
Copy link
Contributor

@ryzngard ryzngard left a comment

Choose a reason for hiding this comment

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

overall lgtm

public override Task<T> GetAssetAsync<T>(Checksum checksum, CancellationToken cancellationToken)
=> _validator.GetValueAsync<T>(checksum);
public override async ValueTask<T> GetAssetAsync<T>(Checksum checksum, CancellationToken cancellationToken)
=> await _validator.GetValueAsync<T>(checksum).ConfigureAwait(false);
Copy link
Contributor

Choose a reason for hiding this comment

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

❓why do we await here instead of just returning the value task?

Copy link
Member Author

Choose a reason for hiding this comment

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

because _validator.GetValueAsync returns a Task, nto a ValueTask. This is a simple way to map between them.

@@ -52,24 +52,22 @@ public override async Task<T> GetAssetAsync<T>(Checksum checksum, CancellationTo
}
}

public async Task<List<ValueTuple<Checksum, T>>> GetAssetsAsync<T>(IEnumerable<Checksum> checksums, CancellationToken cancellationToken)
public async ValueTask<ImmutableArray<ValueTuple<Checksum, T>>> GetAssetsAsync<T>(HashSet<Checksum> checksums, CancellationToken cancellationToken)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we use an Immutable type here?

@CyrusNajmabadi
Copy link
Member Author

Should we use an Immutable type here?

On the input side, no. THese are effectively 'scratch' sets where we're computing work to do, doing the work, then returning the scratch sets to the pool. Think of them as the 'set' equivalent to passing around work with a temporary ArrayBuilder. We want to avoid the unnecessary conversion of this to an immutable array as we're not ever storing this.

@CyrusNajmabadi CyrusNajmabadi enabled auto-merge July 29, 2022 20:43
@CyrusNajmabadi CyrusNajmabadi merged commit e2c555e into dotnet:main Jul 29, 2022
@ghost ghost added this to the Next milestone Jul 29, 2022
@CyrusNajmabadi CyrusNajmabadi deleted the syncOverhead branch August 23, 2022 21:16
@dibarbet dibarbet modified the milestones: Next, 17.4 P2 Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants