Skip to content

Conversation

@kerams
Copy link
Contributor

@kerams kerams commented Mar 13, 2021

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
AMD Ryzen 7 3700X, 1 CPU, 16 logical and 8 physical cores
.NET Core SDK=5.0.200-preview.21077.7
  [Host]     : .NET Core 5.0.2 (CoreCLR 5.0.220.61120, CoreFX 5.0.220.61120), X64 RyuJIT DEBUG
  DefaultJob : .NET Core 5.0.2 (CoreCLR 5.0.220.61120, CoreFX 5.0.220.61120), X64 RyuJIT

Method Mean Error StdDev Median Gen 0 Gen 1 Gen 2 Allocated
New3Part 134.50 ns 3.313 ns 9.768 ns 129.21 ns 0.0842 - - 704 B
Old3Part 1,758.37 ns 19.991 ns 18.699 ns 1,757.57 ns 0.1755 - - 1480 B
New1Part 14.62 ns 0.330 ns 0.309 ns 14.68 ns 0.0115 - - 96 B
Old1Part 283.67 ns 2.794 ns 2.614 ns 282.73 ns 0.0162 - - 136 B

Tested against

let threePart = (("yup", 1s), 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, Some 12, 13, "nope",  17, 18, ValueSome 19)
let onePart = ("yup", 1s)

There's one little problem though. When values of the wrong type are passed to the precomputed constructor, InvalidCastException is now thrown instead of ArgumentException (MakeTuple still throws this as well). I'm not sure if this matters that much (I suspect a similar change sneaked into #9784), but if it does, I could theoretically emit a runtime check throwing the old exception here at the cost of a small performance hit.

@cartermp
Copy link
Contributor

This is technically a breaking change given the change in exception that's thrown, but I think that's a very minor thing given the perf benefits.

@cartermp
Copy link
Contributor

Could you update the failing test?

@cartermp cartermp added this to the 16.10 milestone Mar 20, 2021
@cartermp cartermp merged commit b4c5af6 into dotnet:main Mar 20, 2021
@kerams kerams deleted the tuple-ctor branch March 20, 2021 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants