Здравствуйте, Sinix, Вы писали:
S>с третьей — в core 3.1 разница уже не так впечатляет
Видимо, это железом объясняется. У меня схожие результаты для Core 3.1.
BenchmarkDotNet=v0.12.1, OS=Windows 10.0.18363.836 (1909/November2018Update/19H2)
Intel Core i7-10710U CPU 1.10GHz, 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=3.1.201
[Host] : .NET Core 2.2.4 (CoreCLR 4.6.27521.02, CoreFX 4.6.27521.01), X64 RyuJIT
.NET Core 3.1 : .NET Core 3.1.3 (CoreCLR 4.700.20.11803, CoreFX 4.700.20.12001), X64 RyuJIT
Job=.NET Core 3.1 Runtime=.NET Core 3.1
| Method | Mean | Error | StdDev | Median |
|------------------- |----------:|---------:|---------:|----------:|
| ReferenceCodeJam | 29.26 ms | 0.306 ms | 0.287 ms | 29.36 ms |
| ReferenceMy | 14.01 ms | 0.214 ms | 0.200 ms | 13.95 ms |
| Referencex5CodeJam | 156.17 ms | 2.488 ms | 2.205 ms | 156.52 ms |
| Referencex5My | 49.88 ms | 0.419 ms | 0.392 ms | 49.97 ms |
| intCodeJam | 29.41 ms | 0.579 ms | 0.594 ms | 29.37 ms |
| intMy | 24.99 ms | 0.499 ms | 0.925 ms | 24.82 ms |
| intx5CodeJam | 118.24 ms | 1.596 ms | 1.414 ms | 118.34 ms |
| intx5My | 86.73 ms | 1.352 ms | 3.240 ms | 85.68 ms |
| longCodeJam | 28.85 ms | 0.236 ms | 0.209 ms | 28.82 ms |
| longMy | 23.51 ms | 0.225 ms | 0.200 ms | 23.51 ms |
| longx5CodeJam | 116.59 ms | 1.507 ms | 1.410 ms | 116.57 ms |
| longx5My | 81.93 ms | 1.235 ms | 1.095 ms | 81.99 ms |
S>Ну, т.е. конкретно этот метод мы втащим, не проблема. А с остальными хэлперами для IEnumerable чего делать?
S>Переписывать всё — не вариант, код итераторов достаточно тяжёлый бывает. Переписать выборочно можно, но кто потом этот код будет поддерживать?
Если бы нашелся человек, который использует CodeJam в продакшене(у меня пока только в коде для тестов) и проверил, есть ли у него заметный выигрыш от применения новых итераторов, то это был бы понятный ориентир.
Может это вообще никому не надо, а если у кого-то будет наблюдаться заметный прирост производительности, то плюс за переписывание
S>Короче, я в раздумьях и не готов топить ни за, ни против.
