Implications de l’utilisation de la communication inter-processus (IPC)

À quel type d’utilisation IPC est-il destiné et est-il correct d’envoyer des blocs JSON plus importants (des centaines de caractères) entre les processus utilisant IPC?

Au fond, IPC est ce qu’il dit sur l’étain. C’est un outil à utiliser lorsque vous devez communiquer des informations entre des processus, quels qu’ils soient. Le sujet est très vaste et inclut techniquement l’allocation de mémoire partagée et la communication manuelle, mais compte tenu du ton de la question et des balises, je suppose que vous parlez des fonctionnalités fournies par le système d’exploitation.

Wikipedia fait un très bon travail en discutant de l’utilisation de l’IPC, et je ne pense pas pouvoir faire beaucoup mieux, alors je me concentrerai sur la deuxième question.

Dois-je essayer d’envoyer un message aussi petit que possible à l’aide d’IPC ou les gains de performance découlant de la réduction de la taille des messages ne valent-ils pas la peine?

Cela sent un peu comme une micro-optimisation. Je ne peux pas dire définitivement, car je ne suis pas au courant du code source chez Microsoft et Apple, et je ne veux vraiment pas explorer l’implémentation d’IPC par le kernel Linux, mais voici quelques points:

1. L’IPC est une opération courante, de sorte que les concepteurs de systèmes d’exploitation sont susceptibles de l’optimiser pour plus d’efficacité. Il y a des équipes d’ingénieurs qui ont pris en compte le problème et ont trouvé comment faire cela rapidement.
2. Le goulot d’étranglement dans la communication entre les processus / threads est presque toujours la synchronisation. Les retards sont mauvais, mais les conditions de course et les impasses sont pires. Cependant, les concepteurs de systèmes d’exploitation disposent de nombreux moyens créatifs pour accélérer la procédure, car le système contrôle le planificateur de processus et le gestionnaire de mémoire.
3. Il existe de nombreuses façons de transférer rapidement les données. Pour le système d’exploitation, si les données doivent traverser les limites des processus, il peut s’avérer nécessaire de les copier, mais le système d’exploitation copie constamment la mémoire. Pensez à un utilitaire de ligne de commande, comme netstat . Lorsque cet exécutable est exécuté, la mémoire doit être allouée, le processus doit être chargé à partir du disque et toute correction d’adresse que le système d’exploitation doit effectuer est effectuée avant même que le processus puisse démarrer. Cela se fait si rapidement que vous remarquez à peine. Sur Windows, netstat est à environ 40k, et il se charge presque instantanément dans la mémoire. (Bloc-notes, un autre chargeur rapide est 10 fois plus gros, mais il se lance encore dans un court laps de temps.)
4. La grande exception à # 2 ci-dessus est si vous parlez de l’IPC entre les processus qui ne sont pas sur le même ordinateur. (Think Windows RPC) Ensuite, vous êtes vraiment lié par la vitesse de la stack réseau / communication, mais à ce stade, quelques ko ici ou là ne vont pas faire beaucoup de différence. (Vous pouvez considérer AJAX comme une forme d’IPC où les «processus» sont le serveur et votre navigateur. Examinez maintenant la vitesse d’utilisation de Google Docs.)

Si l’IPC se situe entre des processus sur le même système, je ne pense pas que cela vaut la peine de faire beaucoup d’efforts pour raser les octets de votre message. Rendez votre message facile à déboguer.

Dans le cas où la communication se passe entre des processus sur différentes machines, vous pouvez penser à quelque chose, après avoir passé beaucoup de temps à déboguer des problèmes simples avec un meilleur format de données, quelques dizaines de millisecondes de plus. ne pas rendre les données plus difficiles à parsingr / déboguer. Rappelez-vous les trois règles d’optimisation ¹ :

1. Ne pas
2. Ne pas encore… (Pour les experts)
3. Profil avant vous

¹ Les deux premières règles sont généralement atsortingbuées à Michael Jackson. ( Celui-ci pas celui-ci )