.NET und dll Callback routinen

[Michael Breier]

Hallo, ich hab da ein Problem. Wir nutzen den CAN Bus eines Rechners für Messtechnische Aufgaben. Für den CAN Bus ist eine DLL für NT/2000 vorhanden. Daten kommen im 50 ms Takt über die Schnittstelle. Jedesmal, wenn Daten ankommen wird eine Callback routine aus der DLL heraus in meiner C#.NET Applikation aufgerufen. Das funktioniert auch soweit, jedoch steigt die Prozessotauslastung bereits bei dieser geringen Datenrate auf 100% (geplant sind Datenraten bis 1 ms). Dazu kommt noch, das die in C# (mittels delegates) implementierte Callback Funktion derzeit noch leer ist, also ohne Funktionalität. D. h., nur der schlichte Aufruf meiner C# Funktion aus der DLL heraus bringt den Rechner (566 MHz Celeron, 128 MByte Speicher) an die Kante. Die Applikation war vorher mit Delphi 7 realisiert, dort konnten wir ein solches Verhalten nicht feststellen.
Für Kommentare wäre ich sehr dankbar.

Gruß
Michael

[Andreas Kosch]

Hallo,

ich gehe einmal aus, das mit der "DLL" eine Win32-DLL und keine .NET-Assembly gemeint ist. In diesem Fall gibt es im Vergleich zu Delphi 7 einen großen Unterschied, der zu zwei Konsequenzen führt: Bei jedem Callback-Aufruf ist von Wechsel von Managed Code zu Unmanaged Code im Spiel. Dies hat an gleich 2 Stellen in Bezug auf die Performance negative Konsequenzen:

1. In der Voreinstellung greift bei jedem Aufruf (d.h. beim jedem Grenzwechsel) .NET Security ein, um die Einhaltung der Sicherheitsregeln zu prüfen.

2. Der .NET-Marshaler muss die Win32-Datentypen in die kompatiblen .NET-Datentypen transformieren (und das in beiden Richtungen).

Das zweite Problem ist unvermeidbar, in Sachen .NET Security haben wir zwei Eingriffsmöglichkeiten:

a) Attribut <b>SuppressUnmangedCodeSecurity</b> beim Deklarieren der "alten" DLL-Funktion via DllImport

b) Wenn der Rechner niemals mit dem Netz verbunden wird, kann das .NET Security-Subsystem mit Adminiatrator-Rechten komplett abgeschaltet werden: <b>Caspol -security off </b> - vorher aber gut nachdenken ;-)

P.S: In Delphi 8 kann über die VCL.NET der bremse Einfluss von P/Invoke sehr augenscheinlich nachvollzogen werden. Ein Testprogramm fügt 500 Einträge in ein TreeView-Control ein: <br>
a) Delphi 7 + VCL: 90 Millisekunden Zeitbedarf <br>
b) Delphi 8 + VCL.NET: 2000 Millisekunden Zeitbedarf <br>
c) Delphi 8 + FCL: 110 Millisekunden Zeitbedarf<br>
Da die VCL.NET intern ständig über P/Invoke die alten Win32-API-Funktionen direkt aufruft, ist dieser riesige Bremsfaktor unvermeidlich. Nur wenn die FCL (Windows Forms) aus dem .NET Framework verwendet wird, ist Delphi 8 fast so schnell wie Delphi 7