Как я понимаю, .net'овский async в итоге задействует Overlapped IO. Если это так, то в моих замерах потоковая скорость немного проседает, но и cpu также меньше грузится. Пока глубоко не исследовал. Упоминал в конце статьи про Async/await.
FILE_FLAG_NO_BUFFERING в dotnet'е в явном виде нет, работает(?) как хак. Нет, не смотрел, но спасибо за наводку.
FILE_FLAG_WRITE_THROUGH в нашем случае, как я понимаю, не актуален, т.к. запись идёт последовательно и большими объёмами. А с ним скорость в этом сценарии будет меньше. Или я не прав?
Полноценного тестирования на разных файловых системах с тюнингом их параметров не делали. ИМХО, кроме размера кластера и внутреннего кэширования там мало что на результат влияет в нашем случае (чтения большого файла).
Win+NTFS и Linux+BTRFS при дефолтных параметрах на одинаковом железе на глаз выдают примерно одинаковые результаты.
HDD сразу в пролёте. SSD — наше всё. Optane — пока не завезли.
SATA, конечно, хуже NVME, но тестировали полноценно только на первом. В NVME, конечно, скорость будет повыше. Индекс просто перестал быть узким местом в поиске, упираемся в последующие стадии.
Омоглифы (замену банального о=>o) мы стали ловить ещё где-то в 2011 году. Полноценно проблему решили примерно в 2015. Ещё встречается, но довольно редко. На новых языках или если где недосмотрели в новых чекерах. Но довольно быстро затыкаем, как только обнаруживаем.
Про технические способы обнаружения обхода мы выпустим полноценную статью в этом году. И, видимо, не одну!
У O(1) можно либо константу уменьшить (о которой часто забывают), либо вообще обойтись без поиска (т.е. константу свести к нулю). В нашем случае иногда читать с диска не требуется, что можно считать вторым случаем.
А разве тот же protobuf не кодирует однозначно? Зачем использовать много байт при кодировании нуля, когда можно задействовать один. Имхо, проблема несколько натянута. Но за статью спасибо.
FILE_FLAG_NO_BUFFERING в dotnet'е в явном виде нет, работает(?) как хак. Нет, не смотрел, но спасибо за наводку.
FILE_FLAG_WRITE_THROUGH в нашем случае, как я понимаю, не актуален, т.к. запись идёт последовательно и большими объёмами. А с ним скорость в этом сценарии будет меньше. Или я не прав?
Про уникальные слова я не понял идею. Можете разъяснить?
Win+NTFS и Linux+BTRFS при дефолтных параметрах на одинаковом железе на глаз выдают примерно одинаковые результаты.
HDD сразу в пролёте. SSD — наше всё. Optane — пока не завезли.
SATA, конечно, хуже NVME, но тестировали полноценно только на первом. В NVME, конечно, скорость будет повыше. Индекс просто перестал быть узким местом в поиске, упираемся в последующие стадии.
Омоглифы (замену банального о=>o) мы стали ловить ещё где-то в 2011 году. Полноценно проблему решили примерно в 2015. Ещё встречается, но довольно редко. На новых языках или если где недосмотрели в новых чекерах. Но довольно быстро затыкаем, как только обнаруживаем.
Про технические способы обнаружения обхода мы выпустим полноценную статью в этом году. И, видимо, не одну!
Про O(0) — это, конечно, была шутка.