J'ai deux fichiers comme ceci:
FILE1
a 23 100 a 24 221 a 34 0 b 45 345 b 34 0 b 44 344 b 1 0 c 45 190 c 43 0
4 Réponses :
Pourquoi pas seulement la boucle sur elle? Ceci est itinéraire inefficace, mais si les fichiers sont petits, cela pourrait tout simplement pas importer. des commentaires que je vois, que les fichiers sont modératement dimensionnés, nous avons donc besoin d'une solution plus efficace: nous pouvons garder la boucle, mais nous devons nous débarrasser de la boucle réussite que vous pouvez ignorer le tri si les fichiers sont déjà triés. grep . Nous faisons cela en triant:
Mes fichiers sont trop gros (plus de 70 millions de lignes) afin que cela faudrait beaucoup de temps, je pense.
@VPers: Dans votre question, les informations avec les 70 millions de lignes sont manquantes. Je recommande de ne pas marquer votre question avec bash si vous pensez bash est trop lent pour 70 millions de lignes.
Voir Pourquoi-is-utiliser -A-shell-boucle-to-process-Text-Text-Essenti-Pra Ctitice
@Edmorton envisager (ma réponse dans pure bash ) [ Stackoverflow.com/a/58042021/1765658] , sans fourchettes, quelque chose de plus rapide que celui utilisant awk !
@ F.Hauri J'ai regardé et votre script serait des ordres de magnitude plus lentement qu'un script AWK pour des fichiers d'entrée modérément de taille moyenne. J'ai posté les timings pour des fichiers même minuscules chez Stackoverflow.com/a/58052543/1745001 .
Un dans awk: sortie:
declare -A fnames=() ; declare -a order=()
while read field;do fnames[$field]=0 order+=("$field") ;done <File1
while read a b c;do fnames[$a $b]=$c ;done <File2
for fnam in "${order[@]}";do echo $fnam ${fnames[$fnam]} ;done
a 23 100
a 24 221
a 34 0
b 45 345
b 34 0
b 44 344
b 1 0
c 45 190
c 43 0
Avec les deux fichiers d'entrée postés, cette réponse est la plus rapide à cette question.
Cela semble improbable puisque vous appelez lu dans une boucle (qui est lent) et que vous utilisez des matrices associatives Bash (qui sont aussi lentes) mais même même s'il était vrai - être le plus rapide avec des fichiers minuscules ne sont pas utiles. La solution fonctionnerait en un clin d'œil sur des fichiers minuscules. La performance ne comporte que des fichiers d'entrée non minuscules et votre solution exécuterait des ordres de magnitude plus lentement qu'une solution AWK pour ces fichiers. Je viens de courir les deux et même pour de minuscules fichiers, la solution AWK est plus rapide. Je posterai les résultats dans une réponse.
J'ai posté les timings pour même ces minuscules fichiers à Stackoverflow.com/a/58052543/1745001 et, sur mon système au moins , votre script Shell est plus lent que mon script AWK, même pour ces minuscules fichiers.
Ma réponse est si semblable à @ JamesBrown's Je ne prévoyais pas de le poster mais @ F.Hauri affirma que leur solution Shell était plus rapide que AWK lorsqu'il est exécuté contre les fichiers d'entrée postés, alors voici la comparaison de temps de 3ème exécution entre mon awk script et leur script shell: mais la vitesse relative de l'exécution sur de tels fichiers minuscules n'a pas d'importance car cela se soucie si vous obtenez la Résultat en un clin d'œil vs 2 clignote d'un œil? Lors de l'exécution d'une seule vitesse d'exécution de l'exécution unique, essayons donc d'exécuter des deux fichiers d'entrée modérément générés par ces 2 scripts: et montrant à nouveau la timing 3ème exécution pour éliminer l'impact possible de cache-ing: alors nous pouvons clairement Voir la vaste amélioration du temps d'exécution du script AWK via le script Bash. Les deux scripts ont produit les mêmes valeurs de sortie. Pour comprendre pourquoi le script shell est tellement plus lent que le script AWK Voir la partie de performance de la discussion à Notez que, en plus de courir plus vite, le script AWK est également plus brillant, plus clair et plus portable, donc il y a zéro Avantage de rédiger un script à l'aide de Just Shell Countrines pour cette tâche. Les gars qui ont inventé Shell à la séquence d'appels aux outils et manipuler des fichiers / processus ont également inventé AWK pour que Shell pour appeler à la manipulation de texte à usage général, suivez simplement leur intention des meilleurs résultats. OH, et JUSTE FYI @ JamesBrown's Script a couru sur le même ordre de vitesse que le mien pour les fichiers d'origine: et les fichiers que j'ai générés:
[mythe éclaté]
Essayez
grep -f fichier1 fichier2@ F.Hauri qui produirait des fausses correspondances où
B 1 correspondentB 10 , par exemple.