Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am having performance problems with a small program that is sometimes started very frequently on a machine. It is a 32bit program being run on a 64bit machine. It is called im_comp.exe and is normally placed and run from:

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

Now, if I run this program 150 times from this place, it takes 15 seconds, but if I copy the bin-folder to the desktop and run it from there, it takes only 10 seconds (it is ~30% faster every time, without exceptions). I figured this might have something to do with where the process loads its dlls from, so cleared the path of anything related to TESLA and that does not matter. Then I ran process monitor on a single execution and found a clear difference. In the log from when the program was run from C:\Program Files (x86)\TESLA\bin, there are a lot of entries following this pattern:

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: ...

These entries are missing completely in the log when I run from the Desktop.

Now, there are .Local files both in the desktop bin folder and the other one. Even if I remove all the .Local files from the folders, I still get the same log patterns.

Why does the process try to access dll files in the local directory even though there are no .Local files? Is this a problem based on the program itself or the environment? Is there any way to turn it off, preferably without moving it since it is part of a larger application.

share|improve this question
    
Do you have the same speed "gain" when using C:\Program Files (x86) vs. C:\Program Files? –  0xC0000022L May 24 '12 at 14:22
    
Yes, in fact, it seems like if I put the bin folder anywhere but where it is installed, I get the speed gain. –  erik May 24 '12 at 18:17
    
Well, to me it sounds more like a WOW64 issue than anything else, then. There are special semantics in place for C:\Program Files (x86). –  0xC0000022L May 24 '12 at 19:34

1 Answer 1

This is by design, I believe.

Microsoft allows developers to redistribute components/.dll's that come with Visual Studio, such as Visual Basic related runtimes, etc. So it has not been atypical for many Windows programs to have specific versions of .dll's they depend on in their own application directories, and have a need to use that version over a later version that may be installed on the system.

I have a hunch that during installation Windows can map program file names to known .dll locations (this might even be part of the "Superfetch" service) and therefore not search for them or even preload them. I will bet something like that is going on. Not sure how to turn it off, though.

share|improve this answer
    
Wouldn't your last paragraph imply that the program will run faster from the install directory than from the desktop and not the other way around? –  erik May 24 '12 at 18:20
    
I actually re-read your question and realized what you were saying... Maybe it's a hack inserted by the Windows developers to speed testing or something. Bizzare. –  ultrasawblade May 25 '12 at 0:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.