Jack Mott
Jack Mott
These are such small differences (nanoseconds) it might just be the function call overhead of calling into FirstF. Like the difference is pretty close to the latency of a single...
are you testing with .net core? span is slow when not on .net core
yeah so span being slow is to be expected, nothing to be done about it.
I don't think there would be any performance difference since IEnumerable would still be happening behind the scenes.
If you want, set up a little microbenchmark, doing sum or max or something with an Ilist with linq for using a for loop and the accessor. If there is...
yeah the bounds check probably isn’t getting eliminated when working with an enunerable plus count has function call overhead here probably. its a misoptimization with arrays and lists but good...
not sure, it looks like it should work, I'll investigate
the result of a sum on ushort should be a ushort, the way it is currently implemented. which, won't typically be useful! probably why linq doesn't support it.
ok the problem is that a ushort + a ushort = an int32. So, this could be supported if instead of using a generic sum method, we made one for...
output type always the same as input type currently, same as linq. On Fri, Jul 19, 2019 at 10:11 AM Simon Coghlan wrote: > What would the expected result be...