Discussion :

[johnnyjohnny]

Bonjour,

Je cherche à optimiser un script que j'ai écrit pour trier un fichier de logs, car ces fichiers font généralement plusieurs 1Oaines de Mo et du coup le traitement est long.
J'ai tenté plusieurs méthodes pour lire le fichier (iterateurs, map), mais rien qui n'ait sensiblement changé les choses. Quelqu'un aurait une suggestion ?

Merci à tous

[eyquem]

mais il faudrait en dire plus.

Quel type de données dans ces fichiers ?
Il s'agit de trier des fichiers ou de trier leur contenu ?
Trier en fonction de quoi ?
Faut-il faire des décomptes ?

Parmi les fonctions qui traitent des chaines de caractères, toutes ne sont pas équivalentes au niveau de la vitesse.
Par exemple, si on connait la position précise de x caractères recherchés dans un string,
if chaine[9:9+x]=='x caractères' : sera plus rapide que if chaine.count('x caractères')==1:

[johnnyjohnny]

A partir d'un fichier initial, contenant de nombreuses lignes similaires (mais pas complètement identiques), je cherche à produire un fichier texte contenant une seule occurrence pour un type de message (une sorte de rapport sur les évènements survenus en gros). Mon script me permettrait de ne pas avoir à parcourir à la main le fichier à la recherche d'une ligne sur 10000, et de rendre le fichier de logs plus lisible en écrémant les répétitions).

Voici une partie de mon algorithme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
for line in oError:
    s = get_close_matches(line, errors, cutoff=0.1)
    if s != []:
        i = errors.index(s[0])
        if check[i] == False:
            oReport.write(s[0])
            oReport.write("\n")
            check[i] = True
    else:
        errors.append(line)
        oReport.write(line)
        oReport.write("\n")
        check.append(True)

En gros, pour chaque ligne on recherche la similarité entre les autres. Si la ligne courante est similaire à une de celles enregistrées précédemment, on passe à la suivante, si au contraire elle ne correspond pas à quelque chose de connu, on l'enregistre dans une liste.

[eyquem]

En voyant
for line in oError:
je conclus que tu as dû faire quelque chose comme oError = fichier.splitlines() et que oError est donc une liste de lignes qui occupe un espace mémoire de la taille du fichier initial, plusieurs dizaines de Mo dis-tu.
Le programme a donc affaire à un objet en mémoire (mémoire vive) de plusieurs dizaines de Mo et c'est lourd pour lui, et ça peut être d'autant plus une cause de lenteur que l'ordi est peu performant.
J'ai été dans ce cas, j'ai rapidement compris qu'il fallait que je passe à un traitement séquentiel des mes fichiers, c'est à dire analyser les lignes les unes après les autres, sans garder une ligne une fois analysée.

[johnnyjohnny]

Je n'ai pas utilisé splitlines lors de l'ouverture mon fichier, je vais jeter un oeil de ce côté là.
Par contre j'ai tenté la chose avec fileinput, qui apparemment lis les lignes unes par unes dans le fichier, mais ça n'a pas vraiment amélioré la chose.

[johnnyjohnny]

d'ailleurs, je me pose la question de savoir si :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for line in oError:

est vraiment équivalent à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for line in oError.readlines():

Je crois que les fichiers sont "itérables", ce qui fait que j'obtient le même résultat avec les 2 lignes ci-dessus.

[eyquem]

Pardon, j'ai fait une confusion. splitlines() est une méthode de string.
Je pensais à readlines() en fait.



Finalement c'est quoi oError, c'est défini comment au départ ?
Le fichier qui contient le log est sur le disque dur ?


Je viens d'apprendre quelque chose: j'ignorais qu'on pouvait faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
f = open('goulou','r')
for ln in f:
    print ln
f.close()

[eyquem]

Pour moi:
- si on définit f = open('goulou','r')
on définit un accès à un fichier 'goulou' présent sur un disque dur, avec un pointeur dirigé sur le début du fichier, mais rien n'est encore chargé en mémoire vive. C'est seulement en faisant f.readline() ou f.readlines() qu'on fait passer des données du disque dur à leur enregistrement dans une variable à laquelle est affectée une zone en mémoire vive.
- tandis que si on définit g = open('goulou','r').readlines(), on crée tout de suite un objet g en mémoire vive qui contient toutes les données de 'goulou'

Si c'est bien ainsi, alors
- for ln in open('goulou','r'):
va chercher les données sur le disque dur, en faisant avancer le pointeur sur le disque dur au fur et à mesure de la lecture.
- tandis que
for ln in open('goulou','r').readlines(): va chercher les données dans la mémoire vive

Quelqu'un peut-il me dire si je vois mal les choses svp ?

[johnnyjohnny]

Finalement c'est quoi oError, c'est défini comment au départ ?
Le fichier qui contient le log est sur le disque dur ?

Exactement, défini de la façon suivante : oError = open( './erreurs.txt','r')

[eyquem]

Si oError = open( './erreurs.txt','r')
alors ce à quoi je pensais ne se vérifie pas puisque oError n'est pas d'un bloc en mémoire vive. À mon avis.


Tu peux remplacer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
        oReport.write(line)
        oReport.write("\n")

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        oReport.write(line+"\n")

Sinon, comme je ne connaissais pas get_close_matches() , je ne me sens pas capble de t'aider plus.
Tu aurais peut être intérêt à regarder si d'autres tests que l'utilisation de get_close_matches() ne seraient pas plus efficaces question temps d'exécution.

[N.tox]

Est-ce que ce ne serait pas ceci qui ralentirait la cadence:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
oReport.write(line)
        oReport.write("\n")

Je me dis (peut-être à tord) que le fait d'écrire en pplein dans une boucle demande plus de temps que d'ajouter ce que tu veux écrire dans un string, et écrire ce(s) string(s) une bonne fois pour toutes une fois les boucles terminées, non ?

[yacinechaouche]

+1 N.tox. Limiter les I/O aux disques, même si python doit avoir un buffer pour ça.

[dividee]

En regardant l'extrait de code, je ne vois pas quand check[i] pourra être False, je ne vois donc pas à quoi sert la liste check.

Sinon, tu pourrais recopier le code de get_close_matches (qui se trouve dans Lib\difflib.py) et modifier ce code pour qu'il renvoie directement l'index dans la liste au lieu (ou en plus) de la chaîne, cela éviterait de devoir appeler la méthode index ensuite, qui peut être coûteuse.

Mais en fait, il faudrait profiler le code pour voir ce qui prend réellement du temps...

[johnnyjohnny]

En regardant l'extrait de code, je ne vois pas quand check[i] pourra être False, je ne vois donc pas à quoi sert la liste check.

voici le code en entier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
import os
from difflib import get_close_matches
import fileinput
 
#oError = open( './texte.txt','r')
oError = open( './erreurs.txt','r')
oReport = open( './report.txt','w')
 
errors = ["No RTP packet received",
          "No response for the http GET request",
          "java.net.SocketTimeoutException: Read timed out",
          "HTTP GET request in error: 'GET http://",
          "java.net.SocketTimeoutException: connect timed out"]
check = [False,
         False,
         False,
         False,
         False]
 
for line in oError:
    s = get_close_matches(line, errors, cutoff=0.1)
    if s != []:
        i = errors.index(s[0])
        if check[i] == False:
            oReport.write(line+"\n")
            check[i] = True
    else:
        errors.append(line)
        oReport.write(line+"\n")
        check.append(True)
 
 
#map(lcmp,oError.readlines())
 
oError.close()
oReport.close()

la variable 'check' sert en fait à ajouter de nouvelles erreurs dans la liste 'errors'

sinon je vais jeter un oeil aux sources de difflib, ça me semble être une bonne idée. merci

[dividee]

A regarder de plus près le code dans difflib.py, je suis convaincu que la majorité du temps d'exécution est dans get_close_matches. Donc, pas de salut à moins de changer de librairie. Tu peux toujours essayer avec psyco, ça devrait accélérer les choses.

[johnnyjohnny]

Bon, je dois dire que psyco a un peu amélioré la vitesse d'exécution, mais quand je vois la rapidité d'un "sort | uniq" (évidemment c'est du C, et c'est un peu moins malin), ça me rend dingue.
Merci en tout cas pour toutes vos suggestions.