Dans le cas qui concerne ce thread il n'y a qu'une seule substitution à effectuer et on sait à peu près où elle se trouve. Moins d'une seconde comparé à cinq minutes, je ne dirais pas que ça revient "exactement au même" ;-)
Le troisième cas prends environ cinq minutes, pas deux secondes.maintenant si on considère quelque chose de moins aberrant, et possiblement plus proche de la réalité, à savoir un fichier de 20G avec admettons 200 substitutions a effectuer ("<day>20160202</day>" fait 19 octets, dans 4096 octets on peut en placer à peine plus de 200, donc on est dans un cas encore extrême)
- soit on découpe soigneusement un bloc de 4096 octets qui contient les 200 occurrences, c'est très rapide
- soit on passe par un fichier temporaire comme avec sed -i, c'est très lent
- soit on effectue 200 fois à la suite les appels open, seek, write, close, et c'est un peu plus lent que la première solution, mais ça reste tout de même extrêmement rapide par rapport à la deuxième, pour ainsi dire on ne doit pas excéder une ou deux paires de secondes dans le pire des cas, donc il faut tout de même relativiser
Quand on travaille avec un fichier de 20 Go, le temps pris par de multiples ouvertures/fermetures de fichier peut souvent être considéré comme négligeable, mais je suis bien sûr d'accord avec le fait qu'il ne sert à rien de multiplier les ouverture/fermetures sans raison.un truc simple sinon, tu as déjà essayé de coder une fonction de journalisation dans un programme qui déroule très vite ? l'erreur classique est de mettre open et close dans la fonction, ce qui plombe systématiquement les perfs, la solution adaptée consiste à garder le fichier ouvert et à ne le fermer qu'à la fin du programme, c'est donc que les ouvertures/fermetures de fichier ne sont pas sans conséquence, loin de là
"Pas tant de temps que çà", c'est vite dit...tu parles du grep j'imagine, clairement ça n'est pas optimum, mais on s'en fout la lecture ne prend pas tant de temps que ça, c'est de réécrire tout le fichier dans le cadre d'un fichier temporaire qui est consommateur
Les temps de lecture et d'écriture d'un fichier sont du même ordre de grandeur, quelque chose comme 50 à 100 Mo/s (sauf si tu es sur ssd). Il te faut donc environ 5 minutes pour lire un fichier de 20 Go, puis 5 minutes pour le réécrire. Ce sont bien les 10 minutes dont parle Bouga74. On ne se fout donc pas du tout de la lecture. D'autre part, passer par un fichier temporaire ou pas, ça n'a pas grande importance, c'est même probablement plus rapide que modifier la totalité du fichier original in-situ.
Si. Si les chaines à remplacer se trouvent dans les même blocs disque, tu vas réécrire plusieurs fois ces mêmes blocs, et l'OS va même les re-relire à chaque écriture. Cette deuxième lecture sera cependant en cache.euh... non.
Je ne me mélange pas et c'est bien l'accès aux secteurs physiques du disque qui peut poser problème ici. L'OS va sûrement essayer d'optimiser les écritures multiples vers le même bloc le cas échéant, mais c'est quand même très lourd.je crois que tu te mélanges entre les blocs virtuels qu'on paramètre à dd et les secteurs physiques du disque, dont on a absolument pas connaissance
les blocs définis par bs= et count= sont ni plus ni moins que l'équivalent des paramètres size et nmemb de la fonction fread(3)
Partager