2009-04-30 7 views
0

Préliminaire: L'appelant est un fichier EXE natif qui présente un type d'architecture de «plug-in». Il est conçu pour charger une DLL (par son nom, spécifié comme argument de ligne de commande). Cette DLL doit être native et exporter une signature de fonction spécifique. Le fichier EXE est en C++, ce qui n'est pas trop important puisque le fichier EXE est une boîte noire (ne peut pas être modifié/recompilé). La DLL native peut répondre aux besoins de l'application en implémentant complètement la solution de manière native, dans ladite DLL. Cependant, une exigence est de permettre le travail réel (transformant ainsi la DLL native en un fin wrapper/gateway) à coder en C#. Cela me conduit à 3 options (s'il y a plus, s'il vous plaît partager):Options non gérées à gérées: considérations sur les performances

  1. natif DLL charge un C++/Cli DLL qui fait en interne l'utilisation d'une bibliothèque C# classe
  2. DLL natif interagit avec un objet C# COM via CCW
  3. accueille DLL native CLR et effectue des appels à C# assemblage

un autre exigence est que non seulement la DLL native ont besoin d'un moyen d'envoyer des messages (fonctions d'appel) sur le C#, mais les besoins C# être capable de déclencher des événements/rappel à la DLL native lorsque certaines choses extraordinaires se produisent (comme o pposés à la fermeture et au retour). Maintenant, cette dernière chose, je ne sais pas comment gérer la 3ème option, mais c'est une autre question tout à fait.

Donc, au point: la performance. Toute information concernant ces approches (en supposant qu'ils répondent tous aux exigences)? D'après mon enquête, ma compréhension est plus lourde que 1, mais je ne suis pas sûr à 100%, c'est pourquoi je suis ici. Quant à 3, je n'ai pas encore d'informations.

Donc, si quelqu'un a traité ces (ou connaît une autre option élégante), s'il vous plaît carillon.

Merci!

+0

Je ne connais pas les performances, mais 1 est certainement le plus simple. L'impact sur les performances dépend probablement de la quantité de données à marshaler. Des informations sur la quantité de données qui doit voyager à partir de EXE <--> DLL? – Steven

+0

La communication est principalement de Native à Managed sous la forme de petits paquets fréquents (256 octets + ou-). La communication du Managed Back vers le Native sera rare, et dans des paquets très courts. –

Répondre

0

J'ai déjà fait l'option 1, avec un succès raisonnable. Je ne me souviens pas d'implications significatives en termes de performances, même si mon application n'était pas très gourmande en performance. Il me semble que si des problèmes de performance se produisent, un coupable probable pourrait être les fréquentes, petites transitions natives-à-gérés. Serait-il possible de grouper ceux de la couche C++/CLI?

Questions connexes