J'ai 3 choix à utiliser: sockets, activeX, com, afin de communiquer entre les applications sur un ordinateur. Qui est plus rapide?
7 Réponses :
Il est difficile de dire qui est plus rapide, mais l'utilisation de COM est certainement la plus flexible des choix que vous avez énumérés. Sauf si vous aimez Groveling à travers des ruisseaux d'octets.
Eh bien, pensez-y - socket est le niveau le plus bas, com utilise des sockets, ActiveX utilise COM. Alors lequel est plus rapide? Bien sûr, des sockets. Mais ce n'est que si vous posez des questions sur la vitesse d'exécution du programme et les taux de transfert de données. Le développement de programmes utilisant des sockets peut toutefois être beaucoup plus difficile si vous ne savez pas ce que vous faites. Sans parler que vous pouvez éventuellement proposer une mauvaise implémentation qui sera pire que com. De plus, il n'ya pas beaucoup de composants réutilisables que vous pouvez obtenir pour les sockets lorsque vous utilisez ActiveX, sans oublier que si vous souhaitez communiquer avec MS Office, vous devrez utiliser COM.
En réalité, COM utilise LRPC / LPC (pas les sockets) dans le processus croisé, mais le même cas de machine. LRPC / LPC est très efficace (utilise la mémoire partagée).
@Steve: Les sockets sur la même machine utilisent également une carte IPC. La mémoire partagée ne fonctionnera pas sur le réseau, mais il y a des solutions mais coûteuses et non très efficaces et fiables).
Vous ne donnez pas beaucoup de détails sur ce que vous essayez de faire ou quelles considérations vous devez faire. Par exemple, par "Fast", voulez-vous dire une bande passante élevée? Faible latence? Y a-t-il une possibilité que vous pourriez avoir besoin de communiquer à travers des ordinateurs plus tard? C.
Cela peut ne pas compter réellement ce qui est plus rapide. Si oui, choisissez la méthode qui sera la plus pratique à développer et à entretenir. Il peut être possible de sauvegarder votre propre temps, même si vous ne pouvez pas enregistrer d'exécution mesurable.
Certains d'entre nous sont fiers de faire le meilleur travail possible.
@Jay Choisir l'approche la plus pratique et la plus sécurisable vous permet souvent de faire le meilleur travail possible. Je présume que vous n'écrivez pas tous vos programmes dans le code de la machine !!
@Jay remarque également quelle réponse a été acceptée - celle qui dit essentiellement la même chose que la mienne!
Je déléguerais également l'IPC à un cadre par exemple. As (cadre de communication adaptatif). La mise en œuvre de l'ACE par exemple est stable et sa plate-forme transversale.
Tant que cela fonctionne sur une machine, la communication interprocession est fondamentalement étranglée par la bande passante du bus. Une copie mémoire à mémoire, que ce soit réalisée dans la pile TCP / IP, le code de support de tuyau nommé ou la mémoire partagée. Qui les rend tous aussi efficaces.
Un détail importe cependant, la quantité de données transférée et le nombre de couches logicielles que vous voyagez pour obtenir le travail effectué. La bande passante de bus de mémoire ne manette que lorsque la quantité de données est grande. Ce n'est pas nécessairement le cas pour un protocole d'appel de procédure distant comme com. Seuls les arguments de l'appel de fonction doivent être sérialisés, ce qui ne pourrait être qu'une poignée d'octets si vous ne passez pas de tableaux. Maintenant, la surcharge commence à la matière, il y en a une juste quantité lorsque vous utilisez un protocole de haut niveau tel que COM.
L'inconvénient évident d'utiliser des sockets est que vous devrez écrire vous-même tout le code DE / Serialization. Nontrial si le protocole avec le composant n'est pas simple. Traiter vos heures de travail pour plus de commodité est le choix typique, vous seul pouvez le faire.
ActiveX est plus ou moins un nom de marketing fantaisie sur COM (un composant / contrôle ActiveX est un objet qui prend en charge simplement l'interface iunknown), de sorte que votre choix est vraiment bas à la prise COM VS.
pour la communication de processus croisée, vous peut écrire quelque chose plus rapidement avec des sockets ... Si vous êtes une bonne prise et programmeur Windows, car vous serez seul, car les sockets ne feront essentiellement rien pour vous aider. Cela ne signifie pas que COM n'est pas rapide, ni de mauvaises performances, mais vous pouvez toujours faire de manière théoriquement meilleure qu'un système imprenable de la boîte, mais seulement si vous maîtrisez le tout.
On Dernière chose, si vous devez communiquer avec des produits tiers ou d'autres plates-formes que Windows, les sockets sont plus portables.
-1: quelle est-plus rapide -Type question peut être répondu à toujours en essayant simplement. En dehors de cela, sans plus de détails sur votre problème spécifique, toute réponse serait simplement deviner.
Pour une grande quantité de données, probablement des prises plus rapidement. Pourquoi ne le testez-vous pas?
En désaccord avec space_cowboy: une expérience utile pour mettre en œuvre les trois options de données réalistes pour son cas tiraient sûrement plus de 10 heures de temps de développement. Il convient de demander à la communauté quelle est leur expérience avec ces méthodes dans ce cas.
Vous avez plus d'options: tuyaux, messages Windows (wm_copydata), objets de synchronisation ... y a-t-il une raison pour laquelle vous êtes limité à ceux que vous avez énumérés? Et plus important encore: qu'est-ce que tu l'utilises? De toute évidence, les différentes méthodes IPC existent pour une raison, la question n'est jamais simplement «est une plus rapide que l'autre». Votre contexte spécifique décidera. Si par "communiquer", vous voulez dire simplement déclencher un événement, un message Windows est probablement le plus rapide. Précisez s'il vous plaît
Je dois communiquer avec un produit tiers. Et ils n'offrent que celui indiqué. Et en communiquant, je veux dire transférer des données
@Zlobaton: Évidemment en communiquant, vous voulez dire transférer des données. Ce n'est pas une clarification utile. Une manière? Deux voies? Quelle fréquente? Quel type de données? Combien de débit? Asynchrone? Diffusion? L'expéditeur attend-il une réponse basée sur des données?