Лидеры

Ищу сервер с нормальным онлайном и модом OpenComputers

Также я выяснил, что максимальный размер считываемого блока для компонента filesystem составляет 2048 байт против 512 для компонента drive. И при использовании максимальных размеров блока скорости чтения filesystem и drive уравниваются. Учитывая это знание, я бы выбирал между filesystem и drive, исходя из оптимального размера блока. Но это справедливо для постоянно открытых файлов. В ином случае к затратам на чтение требуется добавить затраты на открытие и закрытие.

Оставлю здесь результат обсуждения в чате по этим двум постам: Я не учёл того, что размер данных, считываемых с кассеты, ограничен лишь размером доступной оперативной памяти, на что мне указал в чате@ProgramCrafter. Поэтому не смотря на то, что для чтения с кассеты требуется потратить один тик на позиционирование плюс один тик на чтение, итоговая скорость чтения с кассеты может оказаться в десятки раз выше скорости чтения жёсткого диска. Но возможность использовать преимущество чтения огромного блока в конченом счёте будет определяться конкретными условиями. Недостаточный запас свободной оперативной памяти даже если и позволит считать блок данных, не обязательно позволит его использовать, это сильно зависит от используемого алгоритма. Также чтение большого блока данных может оказаться попросту ненужным, так как тот же алгоритм B-tree позволяет обойтись меньшим количеством данных, но находящихся в независимых друг от друга блоках. И про затраты в два тика времени также не стоит забывать. Но я не исключаю, что в каких-то применениях лучшую скорость покажет именно работа с кассетами. Например, Lua позволяет быстро находить фрагменты хешей внутри даже больших строк, что позволит не тратить время и оперативную память на полную расшифровку считанного блока данных.