[SOS] article 5: ajout

[anthoine.bourgeois]

 Bonsoir,


> Oui, le principe, je le connais. Ce que je mets en doute, c'est son
> utilité pratique: la plupart du temps, ces initialisations obligatoires,
> c'est trop fois rien (un memset, deux trois variables, peut-être un
> sémaphore), bref, rien de bien violent.
>
> Et vu que c'est trois fois rien, je me demandais si le jeu en valait la
> chandelles finalement, puisque le maintien de la free_list (en dehors du
> slab, ou dans le slab en agrandissant les objets) mange quand même pas
> mal de mémoire, surtout pour des tailles d'objets petites.

Oui c'est vrai mais ses petits rien fois le nombre d'allocation peuvent
devenir un petit quelque chose. De plus, pour le client le code est plus
propre.


> Ouaip, il faudrait regarder, mais encore une fois, j'ai l'impression que
> dans la majorité des cas, y'a vraiment trop fois rien pour
> l'initialisation elle-même.
>
> En plus, ça t'oblige à rendre l'objet dans un état propre, sinon le
> projet qui va l'allouer (et considéré que ça été initialisé une bonne
> fois pour toute par le constructeur) va se manger les pieds dans le tapis.

C'est exact.

>
> Je ne parlais pas des ctor/dtor eux-mêmes, mais bien du maintien de la
> liste des objets libres sans utiliser l'espace mémoire de ces objets. Et
> c'est à cause des ctor/dtor qu'il faut faire cela.
>

Je ne conprend pas ce que tu veux dire. J'ai l'impression d'avoir déjà répondu
à ça. Dit m'en plus s'il te plait.

>
> J'ai pas beaucoup réfléchi, mais je comprends pas comment les free_list
> seules peuvent améliorer les performances. Tu peux m'en dire plus ?

C'est vrai que ça n'a pas de rapport. C'est l'implémentation un peu différente
qui à donné cet écart.


Anthoine Bourgeois