En C # /. NEt fait un type dynamique prend moins de place que l'objet?

Question

J'ai une application console qui permet aux utilisateurs de spécifier les variables à traiter. Ces variables sont disponibles en trois saveurs: chaîne, double et long (avec double et long étant de loin les types les plus couramment utilisés). L'utilisateur peut spécifier que les variables qui leur plaisent et dans l'ordre que si mon système doit être capable de gérer cela. À cette fin, dans ma demande que j'avais comme le stockage de ces objets, puis coulée / les uncasting au besoin. par exemple:

public class UnitResponse
{
    public object Value { get; set; }
}

Je crois comprendre que les objets boxed prennent un peu plus de mémoire (environ 12 octets) d'un type de valeur standard.

Ma question est: serait-il plus efficace d'utiliser le mot-clé dynamique pour stocker ces valeurs? Il pourrait contourner le problème de la boxe / unboxing, et si elle est plus efficace comment serait cette performance d'impact?

EDIT

Pour fournir un contexte et éviter le « vous que vous utilisez assez de RAM pour inquiéter à ce sujet » dans mon pire des cas, je 420,000,000 datapoints à vous soucier (60 variables * 7.000.000 enregistrements). Ceci est en plus d'un tas d'autres données que je garde sur chaque variable (y compris quelques booléens, etc.). Réduisant ainsi la mémoire a un impact énorme.

Answer 1

OK, donc le real question ici est «J'ai une connerie ensemble de données énorme que je stocke en mémoire, comment puis-je optimiser ses performances dans le temps et l'espace mémoire? »

Plusieurs pensées:

• Vous êtes tout à fait raison à la haine et la boxe de la peur. La boxe a de gros frais. Tout d'abord, oui, objets en boîte prendre mémoire supplémentaire. En second lieu, les objets sont stockés en boîte sur le tas, pas sur la pile ou dans les registres. Troisièmement, ils sont des ordures collectées; chacun de ces objets doit être interrogé au moment de GC pour voir si elle contient une référence à un autre objet, qu'il ne le sera jamais, et qui est beaucoup de temps sur le fil de GC. Vous devez certainement faire quelque chose pour éviter la boxe.

Dynamique ne l'est pas; c'est la boxe ainsi que beaucoup d'autres frais généraux. (La dynamique C # 'est très rapide par rapport à d'autres systèmes de répartition dynamique , mais ce n'est pas rapide ou faible en valeur absolue).

Il est brut, mais vous pouvez envisager d'utiliser une struct dont les actions mise en page mémoire entre les différents domaines - comme une union en C. Cela est vraiment vraiment brut et pas du tout sécuritaire mais il peut aider dans des situations comme celles-ci. Faites une recherche sur le Web pour « StructLayoutAttribute »; vous trouverez des tutoriels.

• Long, double ou chaîne, vraiment? Ne peut pas être int, float ou une chaîne? Est-ce que les données soit vraiment au-delà de plusieurs milliards de grandeur ou précis à 15 décimales? Ne serait pas int et float faire le travail pour 99% des cas? Ils sont la moitié de la taille.

Normalement, je ne recommande pas d'utiliser float plus du double parce que son une fausse économie; les gens de cette façon souvent économiser quand ils ont un numéro, comme les économies de quatre octets va faire la différence. La différence entre 42 millions et 42 millions de flotteurs doubles est considérable.

• Y at-il une régularité dans les données que vous pouvez exploiter? Par exemple, supposons que vos 42 millions de disques, il n'y a que 100000 valeurs réelles pour, disons, chaque long, 100000 valeurs pour chaque double, et 100000 valeurs pour chaque chaîne. Dans ce cas, vous faites un stockage indexé de quelque sorte pour les désire ardemment, doubles et des chaînes, puis chaque enregistrement obtient un entier où les bits faibles sont l'indice, et les deux premiers bits indiquent que le stockage pour l'obtenir sur. Maintenant, vous avez 42 millions de disques contenant chacun un entier, et les valeurs sont stockées dans quelque forme compacte bien un autre endroit.

• Stocker les booléens comme bits dans un octet; propriétés écrire pour faire le décalage de bits pour obtenir « em out. Epargnez-vous plusieurs octets de cette façon.

• Rappelez-vous que la mémoire est en fait l'espace disque; RAM est juste un cache pratique sur le dessus de celui-ci. Si l'ensemble de données va être trop grand pour garder dans la mémoire vive puis quelque chose va à la page en arrière sur le disque et le relire plus tard; qui pourrait être vous ou il pourrait être le système d'exploitation. Il est possible que vous en savez plus sur votre localité de données que le système d'exploitation ne. Vous pouvez écrire vos données sur le disque dans une forme pratique paginable (comme un b-arbre) et être plus efficace sur le maintien des choses sur le disque et ne la mettre en mémoire lorsque vous en avez besoin.

Answer 2

Je pense que vous cherchez peut-être à la mauvaise chose ici. Rappelez-vous ce que fait dynamique. Il commence à nouveau le compilateur, dans le processus, lors de l'exécution . Il charge des centaines de milliers d'octets de code pour le compilateur, puis sur chaque site d'appel, il émet des caches qui contiennent les résultats de l'IL pour chaque opération de dynamique fraîchement émis. Vous passez quelques centaines de milliers d'octets afin d'économiser huit. Cela semble être une mauvaise idée.

Et bien sûr, vous n'enregistrez pas quoi que ce soit. « Dynamique » est juste « objet » avec un chapeau de fantaisie sur. objets « dynamiques » sont toujours mis en boîte.

Answer 3

Non

. dynamic doit faire avec comment les opérations sur l'objet sont effectuées , pas comment l'objet lui-même est stocké. Dans ce contexte particulier, les types de valeur seraient encore mis en boîte.

En outre, est tout cet effort vaut vraiment la peine de 12 octets par objet? Certes, il y a une meilleure utilisation de votre temps que de sauver quelques kilo-octets (si cela) de RAM? Avez-vous prouvé que l'utilisation de la RAM par votre programme est en fait un problème?

Answer 4

Non

. Dynamique tout simplement le stocker sous forme d'un objet.

Il y a des chances que c'est un micro optimisation qui fournira peu à aucun avantage. Si cela ne devient réellement un problème, alors il y a d'autres mécanismes que vous pouvez utiliser (génériques) pour accélérer les choses.