Очевидно, что если вы можете буферизовать все данные в памяти, (и если хост-система может поддерживать рабочий набор страниц, достаточно большой, чтобы позволить всем этим на самом деле остаются в оперативной памяти без подкачки, то это, вероятно, будет самым быстрым из возможных подходов.
Но будьте очень осторожны при рассмотрении «скрытого дискового ввода-вывода», вызванного подсистемой подкачки виртуальной памяти! Если запрошенные данные "в памяти" на самом деле не находятся "в памяти", произойдет ошибка страницы, и ваш процесс остановится до тех пор, пока страница не будет получена. (А если происходит «кража страницы», то у вас проблемы. Ваша стратегия «в памяти» только что превратилась в, возможно, очень неэффективную (!) стратегию на основе диска. Если ключи распределяются случайным образом, значит, ваш процесс гигантский рабочий набор, к которому он обращается случайно. Если вся эта память на самом деле не находится в памяти, и останется там , у вас проблемы.
Если вы обновляете большой файл, рассмотрите возможность сортировки дельта-файла обновлений перед его обработкой, чтобы все вхождения одного и того же ключа были рядом. Теперь вы можете написать свою программу на языке COBOL, чтобы воспользоваться этим преимуществом (и, конечно же, abend
, если когда-либо будет обнаружена запись с нарушением последовательности!). Если ключ в "этой" записи идентичен ключу "предыдущего", то запись перечитывать не нужно. (И на самом деле вам не нужно записывать старую запись, пока ключ не изменится.) Поскольку метод доступа к индексированному файлу представлен последовательностью ключей, каждый ключ, скорее всего, будет " близко к запрошенной ранее, так что некоторые из необходимых страниц индексного дерева уже будут в памяти. Очевидно, вам нужно будет сравнить это, но количество времени, затраченное на сортировку файла, может быть намного меньше, чем количество времени, затраченное на поиск по индексу. (Что на самом деле может быть значительным.)
person
Mike Robinson
schedule
24.06.2016