DLL code is much slower than main program code

[Jens-Arne]

Hello,

I've written some quite complicated code that deals with custom drawing list views. It is super fast when it is compiled into a main exe file, but when it is situated in a dll it slows down to 1/10 of the original speed or so. No changes to the code, doesn't matter if it is 32bit or 64bit, native or C-backend.

The code makes extensive use of Windows API calls. I couldn't pin it down to a specific bit of code, it is just incredibly slow over the whole thing even at the beginning when variables are set up etc. for no apparent reason. Does anybody have a clue what could be the problem here? Natively compiled code should be at exactly the same speed, no matter if it was located in the main exe or in a dll - code is code.

One last thing: Debugger, purifier and enhancer are disabled both in the main program and in the dll.

Regards, Jens-Arne

[Caronte3D]

Maybe you are making an huge amount of dll calls, that should be slower than direct execution?
(I don't know, just thinking)

[Jens-Arne]

@Caronte3D: Thank you for your reply, but no, this is not at all the case here. At first things are set up with a bunch of dll calls, but then everything runs "on its own" through a subclass function. That is the place where all the drawing takes place, and this subclass function is called by Windows just the same way in an exe as it is in a dll. That's what makes things so very much puzzling.

Moreover, function calls should be equally fast in the exe code and in the dll code. It's always the same register shuffling taking place with function calls, but the technique is all the same. Save registers, call entry point (whereever it might reside in memory), restore registers.

[chi]

If you don't use AttachThread/DetachThread you could try

Code: Select all

ProcedureDLL AttachProcess(Instance)
  DisableThreadLibraryCalls_(Instance)
EndProcedure

But without any code, just a hunch...

[Jens-Arne]

@chi: Interesting function, didn't know this one, thank you. But it makes no difference in this case. As far as I understand it only changes the behaviour of the DLL when it is loaded/unloaded, and especially when this is done by a thread. At least my test program is single-threaded and (un)loads the DLL only once.

[chi]

...and you followed the rules? (Help/Building a DLL)

Code: Select all

Notes about creating DLL's: 

- The declaration of arrays, lists or map with Dim, NewList or NewMap must always be done inside the procedure AttachProcess. 
- Don't write program code outside procedures. The only exception is the declaration of variables or structures. 
- Default values in procedure parameters have no effect. 
- DirectX initialization routines must not be written in the AttachProcess procedure. 

Other than that, create a stripped down version of your dll and trial & error . Use OutputDebugString_("..") and DebugView / DebugView++ inside your dll to track the flow or check the timing.

[Jens-Arne]

All rules followed. No change.

[HeX0R]

Antivir disabled?

[Jens-Arne]

Antivir was not the problem.

I found the bottleneck and got rid of it. But one thing remains: It wasn't a bottleneck in plain PB code but got extremely slow in a PB-DLL. I still don't know why. it was down to the fact that I was assembling a string out of substrings with a delimiter only to rip it apart again using StringField. But again, it is fast in an ordinary EXE and extremely slow in a DLL. The exact same code. That remains strange and a little worrysome. Is there something askew with string handling in PB-DLLs?

[AZJIO]

Make two test cases to prove it. One for the executable file, the other for the dll.
Without seeing the code, it is impossible to take your word for it. And to solve a problem that doesn't exist

[Jens-Arne]

Of course you're right on that. I'll try. But not today. Maybe I'm wrong after all, I just need a little rest to reconsider and think about the way to prove or falsify it with as simple a piece of code as possible.

[Thorium]

Do you use the C-Backend with optimization?
If yes, disable it and see if the standalone is a as slow as the dll.
The only guess i have is that the compiler does some optimization magic and inlines a bunch of stuff, which it can't do on the dll because it's dynamically linked in.

[Jens-Arne]

No, it was the native compiler without optimizations. As I progressed with the work on the project I felt at some point like the DLL wasn't slower than the normal code anymore. I know that this is a little fuzzy but at the beginning the slowdown was dramatic, lateron it wasn't that percievable anymore. It might really have been my fault, that's my best guess at the moment. Honestly I am unable to supply some test code that reproduces this experience reliably.