Медленное выполнение процесса из-за ненужных поисков DLL

818
erik

У меня проблемы с производительностью небольшой программы, которая иногда запускается на компьютере очень часто. Это 32-битная программа, работающая на 64-битной машине. Он называется im_comp.exe и обычно размещается и запускается из:

C:\Program Files (x86)\TESLA\bin 

Теперь, если я запускаю эту программу 150 раз из этого места, это займет 15 секунд, но если я скопирую папку bin на рабочий стол и запустите ее оттуда, это займет всего 10 секунд (каждый раз это на ~ 30% быстрее, без исключений). Я подумал, что это может иметь какое-то отношение к тому, откуда процесс загружает свои библиотеки, поэтому очистил путь от всего, что связано с TESLA, и это не имеет значения. Затем я запустил монитор процесса для одного выполнения и обнаружил явную разницу. В журнале, когда программа запускалась из C: \ Program Files (x86) \ TESLA \ bin, есть много записей, следующих за этим шаблоном:

CreateFile C:\Program Files (x86)\TESLA\bin\im_comp.exe.Local\wow64.dll PATH NOT FOUND Desired Access: ... CreateFile C:\Program Files (x86)\TESLA\bin\wow64.dll NAME NOT FOUND Desired Access: ... CreateFile C:\Windows\System32\wow64.dll SUCCESS Desired Access: ... 

Эти записи полностью отсутствуют в журнале при запуске с рабочего стола.

Теперь есть файлы .Local как в папке bin рабочего стола, так и в другой. Даже если я удаляю все файлы .Local из папок, я все равно получаю те же шаблоны журналов.

Почему процесс пытается получить доступ к файлам DLL в локальном каталоге, даже если нет файлов .Local? Это проблема, основанная на самой программе или окружающей среде? Есть ли способ отключить его, желательно, не перемещая его, поскольку он является частью более крупного приложения.

0
У вас есть такой же «прирост» скорости при использовании `C: \ Program Files (x86)` против `C: \ Program Files`? 0xC0000022L 12 лет назад 0
Да, на самом деле, кажется, что если я положу папку bin куда-нибудь, но там, где она установлена, я получу прирост скорости. erik 12 лет назад 0
Ну, для меня это больше похоже на проблему с WOW64, чем на что-либо еще. Существует специальная семантика для `C: \ Program Files (x86)`. 0xC0000022L 12 лет назад 0

1 ответ на вопрос

1
LawrenceC

Это по замыслу, я считаю.

Microsoft позволяет разработчикам перераспределять компоненты / .dll, поставляемые с Visual Studio, такие как среды выполнения, связанные с Visual Basic, и т. Д. Поэтому для многих программ Windows нетипично иметь конкретные версии .dll, от которых они зависят, в своих собственных каталогах приложений, и необходимо использовать эту версию поверх более поздней версии, которая может быть установлена ​​в системе.

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

Не означает ли ваш последний абзац, что программа будет работать быстрее из каталога установки, чем с рабочего стола, а не наоборот? erik 12 лет назад 0
Я действительно перечитал ваш вопрос и понял, что вы говорите ... Может быть, это взломанный разработчиками Windows взлом для ускорения тестирования или что-то в этом роде. Bizzare. LawrenceC 12 лет назад 0