une string performante?
Dernière réponse : dans Programmation
Bonjour à tous,
Jusqu'à présent, j'utilisais des c-string (un simple tableau de char)
plutot que des c++ string pour des raisons de performance (je n'ai que
récemment découvert les moultes réallocations(!!) des string c++).
Je trouve dommage d'avoir à préallouer à chaque fois ce tableau, car je
me retrouve à hardcoder ces valeurs et il est courant d'allouer bien
plus que nécessaire.
De plus, je ne fais que insérer des
chaines de caractères au début (rarement) et à la fin (toujours). J'ai
aussi parfois besoin supprimer les n derniers caractères (ou de reculer
et de les overwriter ce qui revient au même).
J'ai donc codé une solution intermédiaire à base de listes chaînées de
c-string, en ayant un proxy qui alloue de nouveaux blocks si nécessaire.
Le problème, c'est que je dois maintenir un contexte qui contient des
infos telles que la position du curseur courant du block courant,
l'adresse du block courant etc... Et ce maintient est couteux.
J'ai fait quelques recherches sur le WWW à la recherche de solutions
miracles, et j'ai peut etre trouvé mon bonheur dans les ropes
(http://www.sgi.com/tech/stl/Rope.html), dont l'implémentation GNU
semble être exactement reprise de SGI.
Déjà, pensez-vous que je suis sur une bonne piste?
Si oui, je me demande si je pourrai raisonnablement créer des iovecs à
partir des blocks internes des ropes pour éviter des copies inutiles..
Merci
Jusqu'à présent, j'utilisais des c-string (un simple tableau de char)
plutot que des c++ string pour des raisons de performance (je n'ai que
récemment découvert les moultes réallocations(!!) des string c++).
Je trouve dommage d'avoir à préallouer à chaque fois ce tableau, car je
me retrouve à hardcoder ces valeurs et il est courant d'allouer bien
plus que nécessaire.
De plus, je ne fais que insérer des
chaines de caractères au début (rarement) et à la fin (toujours). J'ai
aussi parfois besoin supprimer les n derniers caractères (ou de reculer
et de les overwriter ce qui revient au même).
J'ai donc codé une solution intermédiaire à base de listes chaînées de
c-string, en ayant un proxy qui alloue de nouveaux blocks si nécessaire.
Le problème, c'est que je dois maintenir un contexte qui contient des
infos telles que la position du curseur courant du block courant,
l'adresse du block courant etc... Et ce maintient est couteux.
J'ai fait quelques recherches sur le WWW à la recherche de solutions
miracles, et j'ai peut etre trouvé mon bonheur dans les ropes
(http://www.sgi.com/tech/stl/Rope.html), dont l'implémentation GNU
semble être exactement reprise de SGI.
Déjà, pensez-vous que je suis sur une bonne piste?
Si oui, je me demande si je pourrai raisonnablement créer des iovecs à
partir des blocks internes des ropes pour éviter des copies inutiles..
Merci
Autres pages sur : string performante
Lassé par la pub ? Créez un compte
remy693 a dit :
Jusqu'à présent, j'utilisais des c-string (un simple tableau de char)plutot que des c++ string pour des raisons de performance (je n'ai que
récemment découvert les moultes réallocations(!!) des string c++).
Je trouve dommage d'avoir à préallouer à chaque fois ce tableau, car je
me retrouve à hardcoder ces valeurs et il est courant d'allouer bien
plus que nécessaire.
De plus, je ne fais que insérer des
chaines de caractères au début (rarement) et à la fin (toujours). J'ai
aussi parfois besoin supprimer les n derniers caractères (ou de reculer
et de les overwriter ce qui revient au même).
J'ai résolu ce problème comme ça :
http://mapage.noos.fr/emdel/clib.htm
Module FSTR (Flexible STRings)
remy693 a dit :
Par contre, je vois que tu fais des réallocations, chose que je souhaitais justement éviter.L'algo (si on peut dire) de réallocation (par doublage), fait que le nombre de réallocations est faible. De toutes façons, il n'y a pas d'autre solutions à ma connaissance (si on veut rester linéaire). D'autre part, tu as dû remarquer que le taille initiale de la chaine était reglable, ce qui permet encore de réduire les réallocations si on connait la taille finale...
Bref, tout ceci est affaire de compromis, et le gain apporté par l'absence de boucles (format interne "adresse, longueur") compense largement les pertes éventuelles duées à la réallocation.
Fait des mesures (notamment sur des chaines longues) pour voir...
Lassé par la pub ? Créez un compte
