PHWinfo banniere

Titres
PORTAIL ANNUAIRE ARTICLES COMPARATEUR HÉBERGEURS DEVIS FORUMS RÉDUCTEUR D'URL
Précédent   PHWinfo > Autres forums > Forum Programmation & Conception > comp.lang.cplus > Strinx-0.62
S'inscrire FAQ Membres Recherche Messages du jour Marquer les forums comme lus
Strinx-0.62

Réponse
 
LinkBack Outils de la discussion
Vieux 03/06/2008, 08h43   #1
shablool
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Strinx-0.62

The Strinx library is a lightweight extension to the standard C++
template library, aimed to provide a set of highly efficient
containers, by using different memory model then traditional STL
containers, which is also less likely to cause memory fragmentations
on long running applications.

Performance benchmarks show that Strinx containers have better
performance then STL containers (on Linux machine, GCC 4.1.2):

http://strinx.sourceforge.net/docs/strinx.html

ShacharS.
  Réponse avec citation
Vieux 03/06/2008, 10h37   #2
bilgekhan
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Strinx-0.62

"shablool" <ssnail@gmail.com> wrote
>
> The Strinx library is a lightweight extension to the standard C++
> template library, aimed to provide a set of highly efficient
> containers, by using different memory model then traditional STL
> containers, which is also less likely to cause memory fragmentations
> on long running applications.
>
> Performance benchmarks show that Strinx containers have better
> performance then STL containers (on Linux machine, GCC 4.1.2):
>
> http://strinx.sourceforge.net/docs/strinx.html
>
> ShacharS.


I haven't tried it out yet but it sounds a good idea.
But I would extend it, so that when the container gets full
that it autom. tries to realloc() the memory with an additional x%
(say 10%) room for new items.

So, the user defines the initial size (ie. nelems) and by this
how much memory to preallocate initally, plus a growing factor
(here 10%). This way it has practically no limits in growing
should the case occur for needing to add even more items
then initially was planned by the user.

It's IMO the most flexible solution. You can keep your design
and just add the above feature of auto-growing of the buffer.
You should also allow the user to change the growing factor
anytime after the inital definition.
You can try this concept out (benchmark) with say the set<T> type.

  Réponse avec citation
Réponse


Outils de la discussion

Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are oui
Pingbacks are oui
Refbacks are oui


Fuseau horaire GMT +1. Il est actuellement 11h09.


Édité par : vBulletin® version 3.7.2
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0 RC5 Tous droits réservés.
Version française #16 par l'association vBulletin francophone
PHWinfo est un site Éducation Sans Frontières
Ad Management by RedTyger
©Tous droits réservés par les parties respectives
Page generated in 0,09755 seconds with 10 queries