Хорошая идея прогреть кеш в блоке BEGIN в Perl? - PullRequest
1 голос
/ 06 февраля 2010

Хорошая ли идея подогревать кеш в блоке BEGIN, когда он привыкнет?

Ответы [ 4 ]

5 голосов
/ 06 февраля 2010

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

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

5 голосов
/ 06 февраля 2010

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

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

2 голосов
/ 06 февраля 2010

Я пойду с «нет», хотя могу ошибаться. Рассуждение происходит следующим образом: размер кода и используемых им данных должен быть небольшим, чтобы он занимал меньше пространства в любых кешах (я предполагаю, что вы имеете в виду кэш ЦП, а не программные хеши с общими результатами запросов или некоторые такая вещь).

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

Раньше я использовал «top», чтобы определять, когда процессы меняются между памятью и диском. Я пока не знаю ни одного хорошего инструмента, чтобы сказать, как часто процесс получает ошибки в кеше и уходит в старую медленную память. Должны быть такие инструменты, я просто еще не знаю, что они (программные инструменты, а не какое-то пользовательское оборудование типа In Circuit Emulator). Возможно, некоторые думали об этом ранее в тот же день ...

1 голос
/ 06 февраля 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...