Dans le cas auquel je pense, c'est vraiment pour de l'optimisation, je suis bien d'accord. Le fait de faire plusieurs programme aurait ralentit le tout. Je parle de lire 10 000 fichiers en quelques secondes.
Sincèrement la lecture de 10 000 fichiers c'est plus les accès disques qui vont te poser problème que l'allocation mémoire. Lancer les lectures de manière asynchrone va probablement te permettre de passer un gap très important. Si ensuite tu as un problème vraiment lors de l'allocation, le fait d'utiliser des thrads (qui peuvent par exemple regrouper les lectures par chunk de 100 fichiers va te permettre d'avoir de simplifier le travail du gc, toutes les allocations annexes seront libérées par la destruction du thread).
Sans piloter le GC, il pourrait être utile d'avoir un moyen de créer des données totalement hors du contrôle du GC. Cela permet d'éviter des scans inutiles. Voir de se passer complètement du GC dans certain cas, par exemple pour les données qui vont rester en vie, durant toute la vie du programme.
Les gc générationnels font déjà se boulot avec une granularité plus fine et de manière plus systématique que ce que tu ferra. Si on prend le cas de la JVM, si vraiment tu as des contraintes fortes qui ne sont pas correctement gérées par défaut tu peux tuner finement la JVM pour gérer par exemple les tailles et les durées des générations.
Pour le cas que je connais le mieux. Le problème principal que je vois aujourd'hui (et qui ne sera jamais corrigé) c'est le coût de l'allocation d'un objet. Les sécurités et autre artifices qui entrent en jeux lors de la création d'un objet peut poser un vrai problème (et ne sont pas forcément facile à prendre en compte (mal grès l'utilisation de pool d'objet).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un langage complexe ?
Posté par barmic . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 3.
Sincèrement la lecture de 10 000 fichiers c'est plus les accès disques qui vont te poser problème que l'allocation mémoire. Lancer les lectures de manière asynchrone va probablement te permettre de passer un gap très important. Si ensuite tu as un problème vraiment lors de l'allocation, le fait d'utiliser des thrads (qui peuvent par exemple regrouper les lectures par chunk de 100 fichiers va te permettre d'avoir de simplifier le travail du gc, toutes les allocations annexes seront libérées par la destruction du thread).
Les gc générationnels font déjà se boulot avec une granularité plus fine et de manière plus systématique que ce que tu ferra. Si on prend le cas de la JVM, si vraiment tu as des contraintes fortes qui ne sont pas correctement gérées par défaut tu peux tuner finement la JVM pour gérer par exemple les tailles et les durées des générations.
Pour le cas que je connais le mieux. Le problème principal que je vois aujourd'hui (et qui ne sera jamais corrigé) c'est le coût de l'allocation d'un objet. Les sécurités et autre artifices qui entrent en jeux lors de la création d'un objet peut poser un vrai problème (et ne sont pas forcément facile à prendre en compte (mal grès l'utilisation de pool d'objet).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)