> Sur un test réalisé par curiosité, la création de 1'000'000+ petits objets dans une boucle est environ 2x plus rapide en ooc qu'en C++
ça montre surtout que l'allocateur mémoire par défaut de ton implémentation de C++ est une bouse pour allouer des petits objets. C'est normal, l'allocateur par défaut doit répondre à diverses problèmatiques sans (trop) sacrifier au niveau des performances.
Le ramasse-miette, la plupart du temps, alloue un pool mémoire au démarrage, il ne rend pas toujours la mémoire libéré par le programme, il peut utiliser différentes politiques, etc.
Certes, ça abaisse le niveau d'entrée pour les développeurs : c'est plus simple, plus efficace et surtout plus sûr que si ils géraient manuellement la mémoire mais ça a un surcoût parfois non négligeable (ie: machine limitée en mémoire)
Après, rien n'empêche le développeur C++ de programmer son propre allocateur mémoire (ce qui arrive très souvent en embarqué ou en programmation temps réel) pour améliorer les performances d'allocation mémoire. Mais pour le côté sûreté et simplicité des garbages collector, les dialectes C++ modernes offre des alternatives tout aussi bien sans surcoût: RAII, pointeurs intelligents avec ou sans comptage de référence, conteneurs etc ...
On n'est pas obligé de choisir entre la gestion manuelle ou automatique de la mémoire, on peut s'orienter vers une gestion semi-automatique comme en C++ ou en Objective-C qui constitue un excellent compromis.
Intrinsèquement, un ramasse miette n'est ni plus lent ni plus rapide qu'une gestion manuelle de la mémoire, ça dépends de la configuration (bcp d'allocations, petits/gros objets, ressources disponibles), ça dépends du développeur (niveau, envie de gérer la mémoire ou pas), du temps alloué au projet, du public visé etc ...
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
ça montre surtout que l'allocateur mémoire par défaut de ton implémentation de C++ est une bouse pour allouer des petits objets. C'est normal, l'allocateur par défaut doit répondre à diverses problèmatiques sans (trop) sacrifier au niveau des performances.
Le ramasse-miette, la plupart du temps, alloue un pool mémoire au démarrage, il ne rend pas toujours la mémoire libéré par le programme, il peut utiliser différentes politiques, etc.
Certes, ça abaisse le niveau d'entrée pour les développeurs : c'est plus simple, plus efficace et surtout plus sûr que si ils géraient manuellement la mémoire mais ça a un surcoût parfois non négligeable (ie: machine limitée en mémoire)
Après, rien n'empêche le développeur C++ de programmer son propre allocateur mémoire (ce qui arrive très souvent en embarqué ou en programmation temps réel) pour améliorer les performances d'allocation mémoire. Mais pour le côté sûreté et simplicité des garbages collector, les dialectes C++ modernes offre des alternatives tout aussi bien sans surcoût: RAII, pointeurs intelligents avec ou sans comptage de référence, conteneurs etc ...
On n'est pas obligé de choisir entre la gestion manuelle ou automatique de la mémoire, on peut s'orienter vers une gestion semi-automatique comme en C++ ou en Objective-C qui constitue un excellent compromis.
Intrinsèquement, un ramasse miette n'est ni plus lent ni plus rapide qu'une gestion manuelle de la mémoire, ça dépends de la configuration (bcp d'allocations, petits/gros objets, ressources disponibles), ça dépends du développeur (niveau, envie de gérer la mémoire ou pas), du temps alloué au projet, du public visé etc ...