MVV

|
Posted: Wed Mar 24, 2010 16:25 Post subject: |
|
|
VadiMGP wrote: | Делать бессмысленную работу? Конечно лень. Тебе показали цифры, согласно которым работа не имеет смысла. Трудозатраты не оправдывают результат. Если ли у тебя другие оценки? Если есть - не делай из этого секрета и сообщи. Только не абстрактно "будет быстрее" а что-то более ощутимое. Хотя бы порядок. Тогда, возможно, я изменю свои выводы. |
Интересно, куда б мы скатились, если б только и делали, что искали подобные цифры и верили им на слово. На твоем месте я бы не радовался так цифрам пятнадцатилетней давности и не надеялся бы на лучшее. Доверяй, но проверяй ©. Тем более, судя по всему, кроме этих цифр у тебя больше контраргументов нет.
VadiMGP wrote: | И какая конкретно зависимость имеется? Наносекунды? А вот мужик, который писал статью, утверждает, что время перебазирования не зависит от размера модуля. Опровергни его цифрами. |
Опять же, какой мужик? Алкаш с перехода? Я тоже много чего могу наговорить. А если посмотреть таблицы в статье по твоей же ссылке, разница по времени между большой и маленькой библиотекой имеется. Так что ты противоречишь сам себе.
Написанная на скорую руку утилита определила время загрузки и выгрузки по предпочтительному и иному адресу (во втором случае я специально выделял блок памяти по предпочтительному адресу функцией VirtualAlloc, заставляя систему перебазировать модуль), совокупное за 1000 итераций:
(виртуальная машина, XP, 1500 МБ ОЗУ, 1 ядро @ 2.66 ГГц)
Quote: | virtualpanel.wfx (119 КБ) - 12368 и 14681 мс
7z.dll (709 КБ) - 13039 и 23924 мс (в 2 раза!)
Imagine.dll (693 КБ) - 56491 и 59365 мс
7zip.wcx (318 КБ) - 16644 и 21110 мс
jdl_avcodec.dll (1164 КБ) - 10506 и 23764 мс
libavcodec.dll (3204 КБ) - 2894 и 53847 мс (тут даже комментировать страшно)
libavcodec.dll (сжатая UPX с --best, 1161 КБ) - 93574 мс и 99894 мс (сжатие почти свело превосходство загрузки по предпочтительному адресу на нет, но тем не менее) |
Последний пример показывает отрицательный эффект сжатия.
Цифры разные для разных модулей, сложно определить зависимость падения производительности от размера модуля, но она все равно заметна, как и общая тенденция.
Желающим потестить выложил утилиту тут (требует MSVCR90.dll).
CaptainFlint wrote: | Однако в Википедии говорится, что винда использует некий таинственный memory mapping, который позволяет даже после таких релокаций шарить код DLL-ки, загруженной в несколько процессов, порождённых одним и тем же EXE-файлом. |
Статья посвящена специальному коду, работающему по любому адресу - судя по всему, он содержит специальный набор инструкций, не содержащих абсолютных адресов или вычисляющих их на ходу. И, исходя из статьи, в Windows такое не используется. |
|