Многоадресная передача отправляет производительность
Ответ: когда можно говорить об отрицательных строках кода. Как в: "Я удалил 40 посторонних строк кода сегодня, и программа все еще функционирует, а также прежде".
4 ответа
Некоторые теории:
Моя первая мысль заключалась в том, что я бы рассмотрел кеширование как фактор здесь - если задачи и значения все еще находятся в стеке или в недавней краткосрочной памяти, вы может обнаружить, что он может отправить их быстрее. По мере увеличения времени вероятность того, что он все еще доступен, уменьшается, поэтому в среднем это займет больше времени.
Однако я бы ожидал, что в этом случае будет верхний предел ... в какой-то момент он всегда в кеше.
Альтернативное объяснение состоит в том, что в вашем приложении / тесте / платформе со временем происходит утечка памяти или некоторое снижение производительности. Это также (если оно существует) означало бы, что чем дольше вы ждете, тем дольше у него будет время для снижения производительности и, следовательно, тем больше времени потребуется на отправку.
ТАКЖЕ - если вы ' Если для их отправки требуется больше времени между пакетами - вы можете превысить время ожидания изучения адресов - как для таблиц IP, так и для таблиц MAC. Если срок действия этих таблиц / кешей истек, им нужно будет заново изучить их перед пересылкой пакета.
Удачи!
Код для выполнения этих задач кэшируется ближе к ЦП (возможно, даже в регистрах), когда только что произошел вызов.
Как вы ждете между посылками? Пробовали ли вы выжидать, чтобы не отказаться от ЦП?
Это может быть артефакт коалесценции прерывания с NIC на данном конкретном хосте, проверьте эту статью 29 West на эту тему, они показывают, как латентность может увеличиться до 125 мкс на e1000 NIC,
http://www.29. west.com/docs/THPM/latency-interrupt-coalescing.html