Tableau de structs ou une structure à réseau pour chacun de ses propriétés

Question

Lors de la conception d'une API, je veux persister les détails (par ex d'un processus en cours) dans mon propre struct personnalisé. Cependant, si je vais le faire pour plus de 1 processus, ce qui signifie que je besoin de plusieurs struct, devrais-je avoir un tableau de struct ou d'un struct avec un tableau pour chacune de ses propriétés (par exemple STARTTIME, PROCESSNAME et d'autres propriétés du processus que je suis intéressé).

Dans quel sens est le meilleur pour la performance et mieux pour une bibliothèque api / classe?

Merci

Answer 1

à mon humble avis, vous devez faire un tableau de struct, en dépit de la baisse de performance que vous prenez pour instansiating toutes les structures. Le sens de l'organisation d'un Etat étant stocké dans un struct l'emporte largement sur la perte de performance, et en utilisant une struct avec un tas de tableaux et qu'assigner chaque processus un index dans un certain nombre de tableaux est très salissant et peut être une énorme douleur à déboguer .

Answer 2

Vous pouvez envisager d'utiliser un class plutôt qu'un struct et j'utiliseriez une liste des classes.

Answer 3

Eric Lippert a quelques arguments contre l'utilisation des tableaux dans une API. L'un des plus convaincant pour moi est pourquoi vous voulez garder la taille de collecte fixe, mais permettent aux consommateurs de modifier le contenu. Vous pouvez voir plus ici .

En fin de compte, vous pouvez les stocker en interne en utilisant des tableaux, mais je voudrais éviter d'exposer ce à travers l'API. Si les gens ont besoin d'énumérer, utilisez IEnumerable à la place.

Answer 4

Du point de vue de stockage de données, si l'on sera souvent accéder à toutes les parties d'un des éléments le plus souvent on accédera à une partie particulière d'un groupe d'éléments consécutifs, le comportement de la mise en cache sera mieux avec un tableau de struct.

Une question plus intéressante est de savoir comment exposer les données. Si vous exposez la struct comme indexeur, tous ceux qui veulent changer un champ de la struct devra lire le struct, modifiez le champ dans leur copie temporaire et écrire en arrière. Vous pouvez exposer les méthodes pour lire / écrire des propriétés individuelles, mais "foo.setBar (100, 23)" semble plutôt moins naturel que "foo (100) .Bar = 23". Trop permettre à cette dernière syntaxe, je vous suggère peut-être avoir l'indexeur revenir un struct avec deux champs privés, « root » et « index », et les propriétés pour chaque champ de la struct de telle sorte que par exemple le poseur de la propriété Bar de l'indexeur effectuerait root.setBar (indice, valeur). L'indexeur devrait également avoir une propriété « asWhateverStructType » pour obtenir / définir la struct dans son ensemble.