BinReadStorage : n'utiliser des bins que lorsque c'est nécessaire

#3392 a mis en évidence que l'espace mémoire est dominé par l'utilisation des bins, au moins lorsque le jeu de données n'est pas clonal (et donc que le nombre de fenêtres est proche du nombre de reads). De manière plus générale on peut penser que ce sera le cas tant que le nombre de fenêtres n'est pas plus un ordre de grandeur en dessous du nombre de reads.

À l'initialisation d'un BinReadStorage (instancié pour chaque clone) on fait :

  if (no_list)
    bins = NULL;
  else
    bins = new list<Sequence>[nb_bins+1];
  score_bins = new double[nb_bins+1];
  nb_scores = new size_t[nb_bins+1];

À lui seul ce bloc représente près de 500 Mo alloués, sur 1,2Go au total.

Le nombre de bins par défaut est défini dans windowExtractor.h :

#define NB_BINS_CLONES 10

On a donc 11 bins par défaut. Et on construit donc des tableaux de 11 listes, 11 double et 11 size_t.

Sauf que typiquement sur ce jeu de données la plupart des clones n'auront qu'un read et donc la grande majorité des bins seront vides. De plus les bins ne sont utiles qu'à partir du moment où on ne peut pas garder tous les reads d'un clone, c'est-à-dire quand la limite de DEFAULT_MAX_AUDITIONED (2000) est franchie. Donc dans la très grande majorité des cas les bins ne servent à rien à part gaspiller de l'espace mémoire.

Il faudrait donc mettre en place le stockage par bins quand le nombre de reads du clone dépasse getMaxNbReadsStored. Ce sera un peu plus coûteux en temps car il faudra redispatcher les reads dans des bins, mais ça devrait rester minime, même sur des échantillons fortement clonaux.