Оптимизация местоположений дисковых данных для последовательного доступа

На современных Ose (Windows, Linux, и т.д.) нет абсолютно ничего, что можно сделать для оптимизации, ищут времена! Вот то, почему:

1. Вы находитесь в системе вытесняющей многозадачности. Ваше приложение и все, это - данные, могут быть сброшены к диску в любое время - пользовательская задача переключателей, экранная заставка умирает, батарея исчерпывает заряд и т.д.
2. Вы не можете гарантировать, что файл непрерывен на диске. Выполнение первого пункта маркированного списка Aaron не гарантирует нефрагментированный файл. Когда Вы начинаете писать файл, ОС не знает, как большой файл будет так, это могло поместить его в небольшое пространство, фрагментировав его, поскольку Вы пишете больше данных в него.
3. Размещение в ОЗУ файл только работает пока размер файла, является меньше, чем доступный диапазон адресов в Вашем приложении. На Win32 количество доступного адресного пространства составляет приблизительно 2 ГБ - память, используемая приложением. Отображение больших файлов обычно включает неотображение и переотображение частей файла, который не будет лучшим из вещей сделать.
4. Помещение данных в центре файла не является никакой справкой как для всего, что Вы знаете, центральная часть файла могла быть наиболее фрагментированным битом.

Для перефразирования Raymond Chen, если необходимо спросить о пределах ОС, Вы, вероятно, делаете что-то не так. Рассматривайте свою файловую систему как неизменный черный квадрат, это просто - то, что это (я знаю, можно использовать RAID и так далее для помощи).

Первый шаг необходимо взять (и должен быть взят каждый раз, когда Вы оптимизируете), должен измерить то, что Вы в настоящее время получали. Никогда ничего не принимайте. Проверьте все с точными данными.

Из Вашего сообщения это кажется, что Вы еще на самом деле не написали кода, или, если Вы имеете, в данный момент нет никакой проблемы производительности.

Единственное действительное решение состоит в том, чтобы посмотреть на большее изображение и разработать методы для получения данных от диска, не останавливая приложение. Это обычно было бы через асинхронный доступ и спекулятивную загрузку. Если Ваше приложение всегда получает доступ к диску и делает работу с небольшими подмножествами данных, можно хотеть полагать, что реорганизация данных кладет весь полезный материал на одно место и другие данные в другом месте. Не зная полной проблемной области не возможно, чтобы быть действительно полезным.

Используйте доступ к файлу с отображенной памятью, а не обычный open-seek-read/write шаблон. Эта техника работает над платформами Unix и Windows.

Таким образом система виртуальной памяти операционной системы обработает кэширование для Вас. Доступы блоков, которые уже находятся в памяти, не приведут ни к какому поиску на диске или время чтения. Записи из памяти назад к диску обрабатываются автоматически и эффективно и не блокируя Ваше приложение.

Примечания Aaron хороши также, поскольку они будут влиять на начальное время загрузки для блока, это не находится в памяти. Объединение, что с техникой с отображенной памятью - в конце концов, легче переупорядочить использование блоков memcpy() чем путем чтения/записи из диска и попытки выгрузок и т.д.

Это - интересная задача. К сожалению, я не знаю, как решить это из поля, также. Подход Corbin звучит разумным мне.

Вот немного предложения оптимизации, по крайней мере: Поместите наиболее полученные доступ объекты в центре Вашего диска (или нефрагментированный файл), не в начале конца. Тот путь, ища на менее используемые данные будет ближе средним числом. Допустите ошибку, это довольно очевидно, все же.

Сообщите нам, выясняете ли Вы решение сами.

Самый простой способ решить это состоит в том, чтобы использовать ОС, которая решает это для Вас под капотом, как Linux. Дайте ему достаточно RAM для содержания 10% объектов в RAM, и это попытается сохранить как можно больше из них в кэше сокращением времени загрузки к 0. Недавние серверные версии Windows могли бы работать, также (некоторые из них не сделал для меня, вот почему я упоминаю это).

Если это не, идут, пробуют этот алгоритм:

• Создайте очень большой файл на жестком диске. Очень важно, чтобы Вы записали это сразу, таким образом, ОС выделит непрерывное место на диске.

• Запишите все свои объекты в тот файл. Удостоверьтесь, что каждый объект является тем же размером (или дайте каждому то же пространство в файле и отметьте длину в первых нескольких байтах каждого блока). Используйте пустой жесткий диск или диск, который просто дефрагментировался.

• В структуре данных сохраните смещения каждого блока данных и как часто к нему получают доступ. Когда к этому получают доступ очень часто, подкачайте его положение в файле с блоком, который ближе к запуску файла и который имеет меньшее количество доступа.

• [РЕДАКТИРОВАНИЕ] Получает доступ к этому файлу с API с отображенной памятью Вашей ОС, чтобы позволить ОС эффективно кэшировать наиболее используемые части для получения лучшей производительности, пока Вы не можете оптимизировать расположение файла в следующий раз.

Со временем блоки, к которым в большой степени получают доступ, будут пузыриться к вершине. Обратите внимание, что Вы можете собрать схемы доступа за некоторое время, проанализировать их и делаете переупорядочивание за ночь, когда существует мало нагрузки на Вашу машину. Или можно сделать переупорядочивание на совершенно другой машине и подкачать файл (и таблица смещения), когда это сделано.

Тем не менее необходимо действительно полагаться на современную ОС, где много умных людей хорошо подумало для решения этих проблем для Вас.