Je pense que l'utilisation de ETS va toujours introduire des effets secondaires similaires.
4 Réponses :
Avantages du dictionnaire ETS Over Process sont:
ETS n'est pas des ordures recueillies car elle est stockée dans un tas en dehors des processus Erlang. Cela signifie que lorsque vous mettez quelque chose dans ETS, il est copié dessus, et lorsque vous le sortez, vous obtenez une copie dans votre processus. Faire de nombreuses recherches ETS peut alors conduire à un excès de consécutation dans votre processus (mais cela n'est pertinent que pour les througuts très élevés).
Le dictionnaire de processus est recueilli à la poubelle. Il est stocké dans le propre tas de processus. Ainsi, lorsque vous avez l'air des choses, vous obtenez une référence à la même valeur que vous y mettez. Les valeurs stockées dans le dictionnaire de processus ne sont pas compactées.
Les deux approches sont non pures, c'est-à-dire qu'ils ont des effets secondaires. Oui c'est mauvais, et oui ce n'est pas pourquoi nous avons les deux alternatives.
Presque tous les livres erlang disent que nous devrions rester à l'écart de la bibliothèque de processus, mais je pense que l'utilisation de l'ETS n'est pas très différente.
"Presque tous les livres erlang" ... Est-ce que cela signifie deux sur trois? =)
Qu'entendez-vous par «compacté» concernant les valeurs stockées dans le dictionnaire de processus? Que signifie "compacté" ici?
ETS est comme un processus Erlang mis en œuvre dans C. Vous pouvez envoyer des rangées de table et récupérer des rangées de table. Il les stockera d'une manière native mise en œuvre en C, dans des espaces de tas recueillis sans ordures. C'est comme ça que je voulais dire compacté. Le dictionnaire de processus n'est que des termes normaux erlang. Mais la différence de compacité ne devrait pas être aussi grosse que celle-ci est dans GC: Ed Heap et vous aurez des problèmes après quelques milliers de lignes. Honnêtement, j'ai écrit ceci 2009 et je ne me souviens pas vraiment de ce que je voulais dire.
ETS se comporte plus ou moins comme si la table était dans un processus distinct et des demandes sont des messages envoyés à ce processus. Bien qu'il ne soit pas mis en œuvre avec des processus que les propriétés de ETS sont modélisées comme ça. Il est en fait possible de mettre en œuvre ETS avec des processus.
Cela signifie que les propriétés d'effet latéral sont compatibles avec le reste de Erlang.
Le dictionnaire de processus n'est comme rien d'autre à Erlang et l'ajout de c'était une grosse erreur. Il n'y a aucune raison d'utiliser le dictionnaire de processus au lieu d'un des dictionnaires de processus locaux tels que dict ou gb_traches.
Je suppose qu'une différence entre ETS et le "ETS basé sur le processus" serait que les premiers peuvent être accessibles vraiment simultanément lors de l'utilisation de serrures fines, tandis que cette dernière appliquera toujours la synchronisation (A.K.A. Serialization).
Pas vraiment d'un processus car l'accès à ETS est synchrone, de sorte que le processus "appelant" doit attendre qu'il s'agisse d'une "réponse" de ETS. La différence est que le dictionnaire de processus sera toujours un dans le contexte de ce processus, tandis que ETS sera un accès synchronisé aux données partagées.
Je vois que Rvirding a commenté et il est l'un des gourous d'Erlang, mais sur ce point, je diffère humblement. Je vois un besoin de dictionnaire de processus (et d'avoir utilisé) les fonctions de ménage dans un processus. Parfois, nous devons stocker l'état dans un processus pour une fonction qui ne fait pas partie de la fonction principale de processus, par exemple un enregistreur peut maintenir l'état et mettre l'état de l'enregistreur dans la logique d'application principale est mauvais.
Pourquoi ajouté le dictionnaire de processus une erreur? Je pense seulement à être donc parce qu'il ouvre la porte pour les effets secondaires. Il semble un bon moyen pour les fonctions appelées par un processus permettant d'accéder aux données du processus, au lieu d'ajouter un argument à toutes les fonctions permettant de transmettre les données spécifiques du processus d'appel. De plus, il semble que, selon un autre poste sur cette page, il est beaucoup plus rapide que les ETS (en fait, il semble une sorte de ETS). S'il vous plaît, clarifiez-moi pourquoi était une erreur. Merci
L'exemple d'utilisation que j'ai donnée dans le commentaire précédent est l'une des utilisations possibles du dictionnaire de processus énuméré dans Comment j'ai appris Pour arrêter de préoccuper et d'aimer le dictionnaire de processus d'Erlang sous le nom "Manipulation de flux de données difficiles dans le code de haut niveau".
Une entrée similaire sur les utilisations du dictionnaire de processus est Sur l'utilisation du dictionnaire de processus à Erlang .
L'opinion de l'équipe de Erlang consiste à "utiliser avec soin" et "ne pas trop utiliser - essayez la version propre en premier" voir Erlang Advanced Topics .
Nul doute que ETS a beaucoup plus de fonctionnalités et est plus sophistiqué. Mais ...
Comme les opérations de mise à jour / de recherche de processus de processus ne déplacent que les références, pas toutes les données (voir la réponse précise de Christian), elle peut être beaucoup plus rapide, en particulier pour les grandes structures de données. Une fois que j'ai refactoré une partie du code pour conserver les structures de données grandes et fréquemment consultées dans Proc. dict au lieu de ETS et nous avons eu une vitesse de 30% dans cette partie du code.
Dans de nombreux cas, les données sont accessibles uniquement par un seul processus. Dans ce cas, je ne vois pas une grande différence théorique entre le proc. Dict et ets. Les deux servent à garder les effets secondaires en mémoire. En outre, vous pouvez accéder au proc.dict d'un autre processus comme
Process_info (où (Net_kernel), Dictionnaire).