Einzelnen Beitrag anzeigen

Kas Ob.
Online

Registriert seit: 3. Sep 2023
353 Beiträge
 
#18

AW: Delphi 7 DLL-Exports überladener Methoden?

  Alt 17. Sep 2023, 10:03
I am sorry if missunderstand the context of this thread.

What i got is you need a way to declare and use functions from a library, and prefer to save on jumps (branching) as much as you can for performance.

If that is the case then i would suggest to drop the whole Delphi default export/import system and use your own:
1) Make your library have a table of pointers to the needed functions (your exports), it is better of that table is simple global record or an global defined array.
2) DLL on loading will fill that table with the addresses of the functions you need to export, this might be ditched if you can manage to declare that table as constant and the compiler manage to full the addresses automatically.
3) Export one function and one only is enough, GetExportTable.
4) well the rest is easy.. i think you got it out from here, as it is easy as it sound for the import part.

See, Delphi compiler generate ugly/slow code for the static imported functions, the calling code will do be like this
.dpr.97: MessageBeep(10);
004D882A 6A0A push $0a
004D882C E847A0F3FF call MessageBeep // <-- this a call to the same EXE

the called MessageBeep inside the EXE is doing such jump, again !!!!!!
:function MessageBeep; external user32 name 'MessageBeep';
00412878 FF2560344E00 jmp dword ptr [$004e3460]

Where the address $004e3460 holds the actual address to MessageBeep the function in user32.dll, and had being resolved by the OS.

So two branching per API call, while if you used my suggestion above (or any other way you see fit), you can save on a jmp/branch, relieving the CPU cache, while allowing any sort of naming you might need.
Kas
  Mit Zitat antworten Zitat