Je suis en train de mettre en œuvre un système qui stocke et manipule beaucoup de chaînes courtes répétitives. Par exemple des séries de prix d'actions. Je vais avoir un grand nombre d'entrées répétitives des cours des actions Microsoft:Boost mouche pour chaînes courtes
<time1>,MSFT,60.01
<time2>,MSFT,60.02
<time3>,MSFT,60.00
Je pense à l'aide Boost::Flyweight pour optimiser l'allocation de mémoire, chaîne recherche/comparaison/coût de la copie de ces petits noms ticker répétitifs (comme MSFT dans ce Cas).
Mais la chose est que ces chaînes sont assez petites pour commencer - habituellement juste quelques octets. Alors qu'un type long est déjà de 8 octets dans les ordinateurs modernes. Cela vaut-il la peine d'utiliser Boost::Flyweight dans ce cas?
Ma compréhension de Boost::Flyweight est que les chaînes intériorisées sont des entiers pour améliorer les performances. Mais je pense que rechercher/comparer/copier une chaîne de 8 octets ne serait pas radicalement différent de fonctionner sur un type de données long de 8 octets. Alors vaut-il la peine de passer à Boost::Flyweight?
Mon objectif principal est plus du côté de l'optimisation de la vitesse que de l'optimisation de la mémoire, si je dois en choisir un.
Quelques pensées viennent à l'esprit: 1) Je ne suis pas au courant de la mise en œuvre de Boost, mais je me sens comme le poids mouche modèle est principalement pour les économies de mémoire, pas de vitesse. 2) Ne pas oublier la localisation du cache. Un poids mouche va certainement être dans une partie différente de la mémoire que tout ce que vous travaillez avec "localement", ce qui signifie des échecs de cache. 3) Si votre compilateur est assez récent, vous devriez obtenir une petite optimisation de chaîne, qui alloue des chaînes sur la pile si elles sont assez courtes. Cela peut faire une plus grande différence que le poids mouche. Mais je pense que vous devriez faire quelques tests pour être sûr. – 0x5453
Je suis d'accord avec @ 0x5453 que, dans ce cas particulier, stocker les chaînes comme des tableaux char à terminaison NUL (par exemple 'std :: array') pourrait être le meilleur pour les performances. Bien sûr cela dépend de l'échelle des allocations –
sehe
@ 0x5453 merci pour votre réponse. Je me sens comme ceci devrait être une réponse pas un commentaire. :) – CodeNoob