Sockets

[adamsitnik]

Fixes #61

Again, I was unable to run this benchmark with xunit-performance so only BDN results below.

Method	Mean	Error	StdDev	Median	Min	Max	Allocated
SendAsyncThenReceiveAsync_Task	73.15 ms	4.205 ms	4.843 ms	72.50 ms	68.03 ms	85.27 ms	64 B
ReceiveAsyncThenSendAsync_Task	340.26 ms	32.494 ms	37.421 ms	332.94 ms	281.82 ms	397.22 ms	320 B
SendAsyncThenReceiveAsync_SocketAsyncEventArgs	70.44 ms	3.795 ms	4.371 ms	68.23 ms	66.51 ms	80.41 ms	1136 B
ReceiveAsyncThenSendAsync_SocketAsyncEventArgs	234.60 ms	3.754 ms	3.511 ms	235.09 ms	227.51 ms	238.87 ms	1424 B

[jorive]

nit: new line at the end of file.

[jorive]

Should we instead control the files to be built at the csproj level? I think that having a single point would be cleaner. Thoughts?

[adamsitnik]

Should we instead control the files to be built at the csproj level? I think that having a single point would be cleaner. Thoughts?

Very good point!

I was thinking about this "problem" and I think that controlling it on .csproj level would be better. We do it already for some other benchmarks.

However I am not sure what we should do:

Specify all the excluded files in explicit way per platform?

Example:

  <ItemGroup Condition=" '$(TargetFrameworkIdentifier)' == '.NETFramework' ">
    <Compile Remove="coreclr\Math\Functions\Single\**" />
  </ItemGroup>

Or maybe introduce some patterns in file names?

Sth like;

Class.Core.cs
Class.Core21+.cs

Example:

  <ItemGroup Condition=" '$(TargetFrameworkIdentifier)' == '.NETFramework' ">
    <Compile Remove="**\*Core*" />
  </ItemGroup>

@jorive what do you think?

[jorive]

I think this pattern is easier to control/monitor:

<ItemGroup Condition=" '$(TargetFrameworkIdentifier)' == '.NETFramework' ">
  <Compile Remove="coreclr\Math\Functions\Single\**" />
</ItemGroup>

@DrewScoggins @adiaaida @brianrob What do you think?

[brianrob]

I agree that controlling the includes in the csproj is much easier to reason about. Rather than using Remove, I'd recommend using <Compile Include="path/to/file.cs" />. This will also work better when we enable things for .NET Framework, which does not use the Core behavior of including all cs files by default. Thoughts?

[adamsitnik]

This will also work better when we enable things for .NET Framework, which does not use the Core behavior of including all cs files by default.

It's dependent on what .csproj are you using, not which framework you target. So if we have a new "sdk style" csproj targeting .NET 4.6 it's going to include all .cs files by default.

[DrewScoggins]

I agree with @jorive. I think that switching on the target framework and removing the pieces that we don't want makes the most sense, but I think that we should make sure to call it out in both comments in both the .csproj file as well as the source of test. Make it very clear where these tests will and will not run.

[adamsitnik]

@jorive I removed the #ifdefine blocks, added the condition to .csproj and added the comments to the code as @DrewScoggins suggested

[jorive]