Связанные с процессором приложения против ввода-вывода

Question

Для приложений в стиле «обработки чисел», которые используют много данных (читается: «сотни МБ, но не в ГБ», т. Е. Они хорошо вписываются в память помимо ОС), имеет ли смысл читать все Прежде чем приступать к обработке данных в память, чтобы избежать возможного ограничения ввода-вывода вашей программы при чтении больших связанных наборов данных, вместо этого загружая их из ОЗУ?

Меняется ли этот ответ при использовании разных данных? т. е. будет ли ответ один и тот же, независимо от того, используете ли вы XML-файлы, плоские файлы, полную СУБД и т. д.?

Answer 1

Ваша программа работает так же быстро, как и ее узкое место. Имеет смысл делать такие вещи, как хранение ваших данных в памяти, если это улучшает общую производительность. Однако не существует жесткого и быстрого правила, которое говорит, что оно улучшит производительность. Когда вы устраняете одно узкое место, узким местом становится что-то новое. Таким образом, решение одной проблемы может привести к увеличению производительности на 1% или на 1000% в зависимости от следующего узкого места. То, что вы улучшаете, все еще может быть узким местом.

Я думаю, что эти вещи обычно вписываются в один из трех уровней:

1. Стремление. Когда вам нужно что-то с диска или из сети или результат расчета, вы идете и получаете или делаете это. Это самая простая программа, самая простая для тестирования и отладки, но худшая для производительности. Это хорошо, если этот аспект не является узким местом;
2. Ленивый. После того, как вы сделали определенное чтение или вычисление, не делайте это снова в течение некоторого периода времени, который может быть от нескольких миллисекунд до бесконечности. Это может значительно усложнить вашу программу, но если чтение или расчет дорог, может принести огромные преимущества; и
3. Слишком рвение. Это очень похоже на комбинацию двух предыдущих. Результаты кэшируются, но вместо чтения или вычисления или запроса существует определенное количество упреждающих действий, чтобы предвидеть то, что вы могли бы хотеть. Например, если вы читаете 10К из файла, существует достаточно высокая вероятность того, что вам может понадобиться следующий блок 10К. Вместо того, чтобы откладывать выполнение, вы получаете его на тот случай, если его попросят.

Урок, который можно извлечь из этого, - цитата Дональда Кнута (несколько чрезмерно используемая и часто ошибочно цитируемая) о том, что «преждевременная оптимизация - корень всего зла». Решительные и чрезмерные решения создают огромную сложность, поэтому нет смысла делать их ради чего-то, что не принесет полезной выгоды.

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

Мое собственное мнение таково: не решайте проблему, пока у вас не возникнет проблема.

Answer 2

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

Большинство таблиц базы данных имеют регулярные смещения для полей в каждой строке. Например, запись customer может иметь длину 50 байт и иметь столбец pants_size, начинающийся с 12-го байта. Выбрать все размеры брюк так же просто, как получить значения со смещением 12, 62, 112, 162, до тошноты .

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