Pour les serveurs, travailler par petits morceau, minimiser les allocations, ce sont de très très bonnes pratiques.
Personne ne dit le contraire, mais des fois tu n'as pas le choix. En plus ça n'est pas toujours vrai.
Déjà, si tu peux faire une opération en mémoire qui va aller vite, il ne faut surtout pas t'en priver. Donc faire un gros malloc et utiliser la méthode lente (avec étude par segment des données, tri du truc, traitement par lot etc.) seulement si le malloc échoue ça fait gagner un paquet de temps.
Ensuite certaine opérations (notamment les bitmap scan des bases de données, un gros map des familles, la décompression de certains formats d'image etc.) ne peuvent se faire facilement qu'en mémoire. Bon après il y a toujours des acrobaties - mais c'est en faisant les acrobaties que tu risques de te prendre des fuites de mémoires, une mauvaise maitrise de la mémoire utilisés et des DOS.
Très honnêtement la méthode qui consiste à tenter d'abord un calloc, puis en cas d'échec on tente le malloc, puis en cas d'échec on attend un peu et on retente un malloc et finalement on fait la méthode lente (ou on envoie un message utilisateur disant que là, c'est loupé), est parfaitement valide dans tout un tas de cas.
Après pour éviter que ca ne vire à la guerre nucléaire totale, il y a toujours les "limit" UNIX. Dans de nombreux cas c'est ça qui va faire filet de secours pour ton système (on est jamais à l'abri d'une fuite de mémoire à la con dans le programme d'à coté).
[^] # Re: Laissez malloc tranquille !
Posté par Kaane . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 4.
Pour les serveurs, travailler par petits morceau, minimiser les allocations, ce sont de très très bonnes pratiques.
Personne ne dit le contraire, mais des fois tu n'as pas le choix. En plus ça n'est pas toujours vrai.
Déjà, si tu peux faire une opération en mémoire qui va aller vite, il ne faut surtout pas t'en priver. Donc faire un gros malloc et utiliser la méthode lente (avec étude par segment des données, tri du truc, traitement par lot etc.) seulement si le malloc échoue ça fait gagner un paquet de temps.
Ensuite certaine opérations (notamment les bitmap scan des bases de données, un gros map des familles, la décompression de certains formats d'image etc.) ne peuvent se faire facilement qu'en mémoire. Bon après il y a toujours des acrobaties - mais c'est en faisant les acrobaties que tu risques de te prendre des fuites de mémoires, une mauvaise maitrise de la mémoire utilisés et des DOS.
Très honnêtement la méthode qui consiste à tenter d'abord un calloc, puis en cas d'échec on tente le malloc, puis en cas d'échec on attend un peu et on retente un malloc et finalement on fait la méthode lente (ou on envoie un message utilisateur disant que là, c'est loupé), est parfaitement valide dans tout un tas de cas.
Après pour éviter que ca ne vire à la guerre nucléaire totale, il y a toujours les "limit" UNIX. Dans de nombreux cas c'est ça qui va faire filet de secours pour ton système (on est jamais à l'abri d'une fuite de mémoire à la con dans le programme d'à coté).