Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Remove FileStream construction cost out of unrelated FileStream benchmarks #841
Comments
|
Nothing sticks out with a cursory glance at the sources. :( @stephentoub, wouldn't the buffer be a good candidate for the new internal GC non zeroing API? cc: @carlossanlop |
I'd prefer to use ArrayPool :) But... that's also not relevant to ReadByte, right (other than that it uses the buffer)? Cost of getting the buffer would only affect first access... presumably we're measuring already-initialized timing here? If not, I'd argue the test is bad :) |
|
Thanks. With "only" 200K iterations inside the test, the cost of creating the FileStream and everything it does, syscalls and allocation and all, could certainly affect the overall perf of the test, considering that ReadByte on most accesses is a few checks and an array access. |
|
We need to update this test to take the construction out of the measurement and make sure we have tests that specifically measure FileStream creation. |
System.IO.Tests.Perf_FileStream.ReadByte(BufferSize: 512, TotalSize: 200000)
System.IO.Tests.Perf_FileStream.ReadByte(BufferSize: 200000, TotalSize: 200000)
/cc @danmosemsft @billwert @DrewScoggins