У вас есть большой файл несколько гигабайт в котором склена куча ресурсов, со своей "файловой системой" и вам нужно вытащить оттуда сотенку ресурсов.

решение в лоб — формально по описанию формата данных читать байты, но результат получается медленный. Хочется понять какие подходы к оптимизации есть,

в настоящее время используется FileStream и BinaryReader,

есть ли смысл кэшировать блоки по 4кб ( или сколько кб физически читается за раз ) например, чтобы не обращаться к диску часто, если данные лежат рядом, или они и так кэшируются на уровне железа и дополнительный кэш в памяти не даст прироста скорости ?
возможно memorymappedfile работает оптимальнее в этих случаях и кэширует исключая лишние обращения ?
какие-то еще есть реализации ?

Здравствуйте, okon, Вы писали:

O>У вас есть большой файл несколько гигабайт в котором склена куча ресурсов, со своей "файловой системой" и вам нужно вытащить оттуда сотенку ресурсов.

.NET юзает MMF для чтения ресурсов. У него супер эффективный кеш по сравнению с FileStream. Чем не устраивает?

O>возможно memorymappedfile работает оптимальнее в этих случаях и кэширует исключая лишние обращения ?
Возможно. Пробуй.

O>какие-то еще есть реализации?
Читай в несколько потоков: shared режим на файле и каждый поток читает по своему смещению.
Применимость зависит от структуры файла.

Здравствуйте, okon, Вы писали:

O>У вас есть большой файл несколько гигабайт в котором склена куча ресурсов, со своей "файловой системой"
ИМХО, сперва подумать о том, чтобы держать таблицу ресурсов в памяти. Причем, не "в лоб", а состряпать что-то типа индекса.

O> и вам нужно вытащить оттуда сотенку ресурсов.
O> решение в лоб — формально по описанию формата данных читать байты, но результат получается медленный. Хочется понять какие подходы к оптимизации есть,
Часто ли приходится тянуть один и тот же ресурс повторно? Может, кэшировать уже вытянутые ресурсы?

O>есть ли смысл кэшировать блоки по 4кб ( или сколько кб физически читается за раз ) например, чтобы не обращаться к диску часто, если данные лежат рядом, или они и так кэшируются на уровне железа и дополнительный кэш в памяти не даст прироста скорости ?
Зачем так вот наугад? Может быть, в структуре файла прослеживаются осмысленные границы блоков. И, опять же, надо анализировать повторные обращения.

Здравствуйте, okon, Вы писали:

O>У вас есть большой файл несколько гигабайт в котором склена куча ресурсов, со своей "файловой системой" и вам нужно вытащить оттуда сотенку ресурсов.
...
O>какие-то еще есть реализации ?
Паркет не пробывали?
https://github.com/elastacloud/parquet-dotnet

Здравствуйте, okon, Вы писали:

O>есть ли смысл кэшировать блоки по 4кб ( или сколько кб физически читается за раз ) например, чтобы не обращаться к диску часто, если данные лежат рядом, или они и так кэшируются на уровне железа и дополнительный кэш в памяти не даст прироста скорости ?

В конструкторе FileStream указываете размер буффера -- чем болше размер, тем меньше обращений к диску, но тем больше RAM будет отжираться. Зависит от файла ресурсов. Выше интересную идею с потоками дали, если
формат заранее известен, т.е. каждый будет читать с определенного места.

S>В конструкторе FileStream указываете размер буффера -- чем болше размер, тем меньше обращений к диску, но тем больше RAM будет отжираться. Зависит от файла ресурсов. Выше интересную идею с потоками дали, если
S>формат заранее известен, т.е. каждый будет читать с определенного места.

C потоками интересно, но немного сомнения берут — будет ли эффект, физически диски они позволяют паралельно читать разные области ?

Здравствуйте, okon, Вы писали:

O>C потоками интересно, но немного сомнения берут — будет ли эффект, физически диски они позволяют паралельно читать разные области ?

Физически нет, но несколько запросов они умеют оптимизировать. Плюс не будет он н будет проста ватт, пока ты забираешь прочитанное и формирует новый запрос на чтение.

Здравствуйте, okon, Вы писали:

O>C потоками интересно, но немного сомнения берут — будет ли эффект, физически диски они позволяют паралельно читать разные области ?

Почему нет? Магнитные же могли на разных пластинах читать одновременно.

O>C потоками интересно, но немного сомнения берут — будет ли эффект, физически диски они позволяют паралельно читать разные области ?
В плане скорости чтения эффект будет.
На уровне драйвера диска все запросы на чтение асинхронные.
Т.е., грубо говоря, когда ты читаешь одним потоком, то это выглядит так: послал запрос в драйвер, запрос встал в очередь, которая шарится между всеми читателями (тут не только твое приложение, а вообще все, что работает с диском).
Твой поток стоит, ждёт пока драйвер ответит. Ответил — послали следующий запрос и т.д.
Если у тебя два потока, то запросы в очередь ставятся в два раза чаще. А значит общая пропускная способность приложения растет.

Здравствуйте, VladCore, Вы писали:

O>>У вас есть большой файл несколько гигабайт в котором склена куча ресурсов, со своей "файловой системой" и вам нужно вытащить оттуда сотенку ресурсов.
VC>.NET юзает MMF для чтения ресурсов. У него супер эффективный кеш по сравнению с FileStream. Чем не устраивает?
Надо понимать, что MMF это не волшебный всемогутер-ускоритель всего, а просто некий алгоритм, реализующий кеш определённым образом (постраничный MRU насколько я понимаю). То же самое и асинхронность в дисках.
Оно ничего не знает о структуре файла и поэтому работает как получится.

Если правильно организовать структуру файла и реализовать чтение его кусков в соответствующем порядке, то можно добиться более значительного прироста производительности.

Это не так уж и тривиально и зависит от характера данных и сценариев их использования. Я бы лучше начал с каких-нибудь стандартных подходов, например, запихать это всё в embedded базу данных или zip-архив.

Здравствуйте, ·, Вы писали:

O>>>У вас есть большой файл несколько гигабайт в котором склена куча ресурсов, со своей "файловой системой" и вам нужно вытащить оттуда сотенку ресурсов.
VC>>.NET юзает MMF для чтения ресурсов. У него супер эффективный кеш по сравнению с FileStream. Чем не устраивает?
·>Надо понимать, что MMF это не волшебный всемогутер-ускоритель всего, а просто некий алгоритм, реализующий кеш определённым образом (постраничный MRU насколько я понимаю). То же самое и асинхронность в дисках.
·>Оно ничего не знает о структуре файла и поэтому работает как получится.

Надо просто знать что MMF не всемогутер, этого никто никто и не говори, но оно всего лиш в 20 раз быстрее на маленьких "записях" в несколько байт.

Здравствуйте, VladCore, Вы писали:

VC>·>Надо понимать, что MMF это не волшебный всемогутер-ускоритель всего, а просто некий алгоритм, реализующий кеш определённым образом (постраничный MRU насколько я понимаю). То же самое и асинхронность в дисках.
VC>·>Оно ничего не знает о структуре файла и поэтому работает как получится.
VC>Надо просто знать что MMF не всемогутер, этого никто никто и не говори, но оно всего лиш в 20 раз быстрее на маленьких "записях" в несколько байт.
Быстрее кого? За счёт чего?
Если сравнивать с FileStream, то "запись" в его внутренний буфер будет сравнимой по скорости.

А ещё я как-то наблюдал ситуацию, когда MMF был сильно медленнее чем обычный file io в условиях когда размер файла был сильно больше доступной RAM и всё нахрен ложилось от постоянных page faults.

Здравствуйте, RushDevion, Вы писали:

RD>Если у тебя два потока, то запросы в очередь ставятся в два раза чаще. А значит общая пропускная способность приложения растет.

А вот енто не факт, поскольку кол-ов эл-ов в очереди также увелиыивается, т.е. если будет 100500 потоков с чтением, то будет bottleneck. Тут надо замерять и искходить из конкретных сценариев.
Корочер, надо вот енту штуку курить -- https://en.wikipedia.org/wiki/Queueing_theory

Здравствуйте, ·, Вы писали:

VC>>·>Надо понимать, что MMF это не волшебный всемогутер-ускоритель всего, а просто некий алгоритм, реализующий кеш определённым образом (постраничный MRU насколько я понимаю). То же самое и асинхронность в дисках.
VC>>·>Оно ничего не знает о структуре файла и поэтому работает как получится.
VC>>Надо просто знать что MMF не всемогутер, этого никто никто и не говори, но оно всего лиш в 20 раз быстрее на маленьких "записях" в несколько байт.
·>Быстрее кого? За счёт чего?
·>Если сравнивать с FileStream, то "запись" в его внутренний буфер будет сравнимой по скорости.

·>А ещё я как-то наблюдал ситуацию, когда MMF был сильно медленнее чем обычный file io в условиях когда размер файла был сильно больше доступной RAM и всё нахрен ложилось от постоянных page faults.

Ты рассчитывал что pagefaults не будет потому что MMF быстрее?

Здравствуйте, VladCore, Вы писали:

VC>>>Надо просто знать что MMF не всемогутер, этого никто никто и не говори, но оно всего лиш в 20 раз быстрее на маленьких "записях" в несколько байт.
VC>·>Быстрее кого? За счёт чего?
VC>·>Если сравнивать с FileStream, то "запись" в его внутренний буфер будет сравнимой по скорости.
VC>·>А ещё я как-то наблюдал ситуацию, когда MMF был сильно медленнее чем обычный file io в условиях когда размер файла был сильно больше доступной RAM и всё нахрен ложилось от постоянных page faults.
VC>Ты рассчитывал что pagefaults не будет потому что MMF быстрее?
Чё? Ты заявил "MMF всего лиш в 20 раз быстрее на маленьких записях" что неправда в подавляющем большинстве случаев.

MMF это просто API, чтобы легче писать код, бегающий по всему содержимому как по плоскому массиву, не мучаясь аккуратным постраничным доступом к файлу, это за тебя делает операционка.
Никакого волшебного ускорения от такого лучше не ждать. Быстрее оно может работать только в определённых условиях.

Здравствуйте, ·, Вы писали:

VC>>>>Надо просто знать что MMF не всемогутер, этого никто никто и не говори, но оно всего лиш в 20 раз быстрее на маленьких "записях" в несколько байт.
VC>>·>Быстрее кого? За счёт чего?
VC>>·>Если сравнивать с FileStream, то "запись" в его внутренний буфер будет сравнимой по скорости.
VC>>·>А ещё я как-то наблюдал ситуацию, когда MMF был сильно медленнее чем обычный file io в условиях когда размер файла был сильно больше доступной RAM и всё нахрен ложилось от постоянных page faults.
VC>>Ты рассчитывал что pagefaults не будет потому что MMF быстрее?
·>Чё? Ты заявил "MMF всего лиш в 20 раз быстрее на маленьких записях" что неправда в подавляющем большинстве случаев.

в 20 раз быстрее на маленьких "записях" в несколько байт.

Как говорится дураки учатся на своих ошибках (с) народная мудрость. Поэтому ты и не смог впихнуть невпихуемое:

·>А ещё я как-то наблюдал ситуацию, когда MMF был сильно медленнее чем обычный file io в условиях когда размер файла был сильно больше доступной RAM и всё нахрен ложилось от постоянных page faults.

·>MMF это просто API, чтобы легче писать код, бегающий по всему содержимому как по плоскому массиву, не мучаясь аккуратным постраничным доступом к файлу, это за тебя делает операционка.
·>Никакого волшебного ускорения от такого лучше не ждать. Быстрее оно может работать только в определённых условиях.

см. народную мудрость или у вас выделения тоже читать не получается? если не получится могу H1 тегом выделить

что ещё непонятно?) поможем! когда конечно прочитаете что и при каких условиях.

Здравствуйте, VladCore, Вы писали:

VC>

VC>в 20 раз быстрее на маленьких "записях" в несколько байт.

VC>что ещё непонятно?) поможем! когда конечно прочитаете что и при каких условиях.
Ответь на вопросы:
Быстрее кого? За счёт чего?

Здравствуйте, ·, Вы писали:

VC>>

VC>>в 20 раз быстрее на маленьких "записях" в несколько байт.

VC>>что ещё непонятно?) поможем! когда конечно прочитаете что и при каких условиях.
·>Ответь на вопросы:
·>Быстрее кого? За счёт чего?

Да забей. Но я себе записал то что ты понаписывал:

[Любое название] — это не всемогутер-ускоритель всего.

[Все что угодно кроме алгоритма] — это просто некий алгоритм, реализующий свои спецефические задачи определённым образом.

шедеврально

Здравствуйте, VladCore, Вы писали:

VC>>>

VC>>>в 20 раз быстрее на маленьких "записях" в несколько байт.

VC>>>что ещё непонятно?) поможем! когда конечно прочитаете что и при каких условиях.
VC>·>Ответь на вопросы:
VC>·>Быстрее кого? За счёт чего?
VC>Да забей.
А ещё мне непонятно накой было врать