à priori, je ferais probablement un truc dans ce gout là, mais il manque quelques infos dans la présentation du problème pour mieux cerner le problème. Par exemple, tu présupposes que le fameux champs 8 peut prendre beaucoup de valeurs différentes, ce qui mènerait à une table de hachage relativement importante, mais c'est un truc à vérifier. La variabilité de ce champs peut changer le choix de la méthode de résolution. Par exemple, si le champ ne peut prendre qu'un nombre relativement restreint de valeurs, on pourrait arrêter de parser les deux fichiers dès qu'on aurait relevé la présence au moins une fois de chaque valeur dans le second fichier.
A partir d'ici, ce commentaire ne s'adresse plus à toi, mais à l'auteur de la question.
Une meilleure connaissance du contexte pourrait aussi aider.
Par exemple, est-ce que c'est un script qui doit être lancé régulièrement ou est-ce que ça ne servira qu'une fois de temps en temps ? Est-ce qu'il y a des contraintes particulières sur le temps de traitement, l'espace disque, la quantité de RAM disponible ? Est-ce que le second fichier est un fichier de référence qui évolue lentement au cours du temps (auquel cas on pourrait maintenir un index des valeurs possibles dans un fichier indépendant et trié), ou est-ce qu'on doit régulièrement comparer deux fichiers dont la taille varie arbitrairement ? Est-ce que les fichiers sont triés sur le champ 8 ? (peu probable, mais si c'est le cas, on peut gagner plein de temps).
Tant qu'on y est, comment sont générés ces fichiers et est-ce qu'on a accès à leur mode de génération ? (genre s'ils sont extraits du BDD à laquelle on a accès, il y a peut-être quelque chose à faire).
[^] # Re: table de hachage
Posté par gaaaaaAab . En réponse au message Traitement de gros fichier. Évalué à 2.
à priori, je ferais probablement un truc dans ce gout là, mais il manque quelques infos dans la présentation du problème pour mieux cerner le problème. Par exemple, tu présupposes que le fameux champs 8 peut prendre beaucoup de valeurs différentes, ce qui mènerait à une table de hachage relativement importante, mais c'est un truc à vérifier. La variabilité de ce champs peut changer le choix de la méthode de résolution. Par exemple, si le champ ne peut prendre qu'un nombre relativement restreint de valeurs, on pourrait arrêter de parser les deux fichiers dès qu'on aurait relevé la présence au moins une fois de chaque valeur dans le second fichier.
A partir d'ici, ce commentaire ne s'adresse plus à toi, mais à l'auteur de la question.
Une meilleure connaissance du contexte pourrait aussi aider.
Par exemple, est-ce que c'est un script qui doit être lancé régulièrement ou est-ce que ça ne servira qu'une fois de temps en temps ? Est-ce qu'il y a des contraintes particulières sur le temps de traitement, l'espace disque, la quantité de RAM disponible ? Est-ce que le second fichier est un fichier de référence qui évolue lentement au cours du temps (auquel cas on pourrait maintenir un index des valeurs possibles dans un fichier indépendant et trié), ou est-ce qu'on doit régulièrement comparer deux fichiers dont la taille varie arbitrairement ? Est-ce que les fichiers sont triés sur le champ 8 ? (peu probable, mais si c'est le cas, on peut gagner plein de temps).
Tant qu'on y est, comment sont générés ces fichiers et est-ce qu'on a accès à leur mode de génération ? (genre s'ils sont extraits du BDD à laquelle on a accès, il y a peut-être quelque chose à faire).