Discussion :

[Pedro]

Salut à tous
J'ai fait un programme de conversion de format de données.
Il lit un très gros fichier texte (qui dépasse allègrement le million de lignes). Dans chaque ligne, il y a X;Y;Z;I comme ceci:

5.963669 -4.981796 -0.462143 25
-8.030930 -5.938217 -0.990524 34
-8.368149 -38.341660 -0.919632 10
-8.365768 -38.329880 -1.116745 10
-8.101089 -35.390182 -0.850754 11
-8.100632 -35.386612 -1.216049 10
-8.101700 -35.392044 -1.033493 11
-1.046555 -36.170578 -1.212143 8
-1.046494 -36.175308 -1.030167 8
-1.046616 -36.167526 -1.394211 8

X, Y et Z sont des réels signés et I est une valeur comprise entre -2048...2047.
Il faut que je fasse la conversion de I pour que l'étendue soit 0..255.
Ce n'est pas le problème de la formule pour faire ça mais plutot la méthode pour Lire/trouver la valeur/la modifier le plus rapidement possible.
Pour l'instant, j'en suis à lire chaque ligne avec ReadLn, trouver la valeur avec DelimitedText de TStringList et réécriture de la ligne avec la même TStringList.
Je cherche une méthode plus rapide. Même quelques millièmes de secondes seront les bienvenus...


d'avance

[Paul TOTH]

tu as testé ceci ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
var
 x,y,z:signed; i:integer;
 f1:textfile;
 f2:textfile;
begin
 assignfile(f1,'fichier1.dat'); reset(f1);
 assignfile(f2,'fichier2.dat'); rewrite(f2);
 while not eof(f) do begin
  ReadLn(f1,x,y,z,i);
  i:=round(256*(i+2048)/4096);
  WriteLn(f2,x,y,z,i);
 end;
end;

[Pedro]

Code :

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

1
2
 
ReadLn(f1,x,y,z,i);

Ca marche ça?? Alors là j'en apprends une belle
Sinon, comment spécifier que le séparateur est un espace ou autre chose? Et au niveau rapidité?

[Paul TOTH]

lol, ça fonctionnait déjà en Turbo Pascal 3 si mon souvenir est bon

tout dépend de l'optimisation du code Delphi, j'en sais rien, sinon il faut faire une lecture par bloques et parser toi même le buffer à la recherche des séparateurs et des fins de ligne.

ou alors, tu fais comme avec .Net et Java...tu dis qu'il faut une grosse machine parce que c'est dépassé que de travailler à l'octet près

[Pedro]

lol, ça fonctionnait déjà en Turbo Pascal 3 si mon souvenir est bon

Eh ben je l'ignorais depuis le Turbo Pascal alors

ou alors, tu fais comme avec .Net et Java...tu dis qu'il faut une grosse machine parce que c'est dépassé que de travailler à l'octet près

La machine qui fait tourner ça est déjà une grosse machine (Bi-Xéon 3Ghz + 3Go RAM)
J'essaie tout ça ce soir

Merci en tout cas

[ShaiLeTroll]

Cette astuce, m'impressionne aussi, ... je viens donc de comprendre pourquoi on peut mettre plusieurs var dans ReadLn, faudra que je teste aussi, parce que si j'avais su ça !

sinon, tu peux remplacer la TStringList par un ExplodeLazy, c'est plus rapide, ensuite, si tu veux modifier le fichier ça se complique car un TextFile c'est en Lecture Seule ...

cherche aussi, l'objet TTextFileReader sur le forum, c'est une classe qui permet de lire un fichier texte (avec la méthode readstring c'est comme un ReadLn), j'avais prévu de la poursuivre pour gérer la modification du fichier, en minimisant le nombre d'opérations de lecture\écriture

[Paul TOTH]

ah tient je remarque une coquille dans mon source, "signed" ça existe pas, je voulais mettre single c'est ma dyslexie qui me reprend

[TicTacToe]

je suis curieux de voir la rapport de vitesse par rapport à un chargement TStringList / traitement / sauvegarde TStringList.

Au niveau mémoire c'est clairement la méthode de lecture/écriture séquentielle ligne à ligne qui est la meilleure, mais si la mémoire n'est pas un problème (rapidement, tes fichiers devraient se situer entre 50 et 200 Mo), ton super Xeon ne devrait pas souffrir de cette prise de mémoire.

Au niveau traitement, il n'y a quasi rien dans les 2 cas.

Donc différence de vitesse
- entre lecture/ecriture séquentielle ligne à ligne (vive le cache)
- lecture en bloc / traitement / écriture en bloc par TStringList.

En tout cas la 1ere méthode est bien plus élégante

Tiens nous au courant !

ps: j'aurais tendance à penser que la 2eme solution est plus rapide même s'il faut ventiler plusieurs fois la liste contrairement à la 1ere...mais je me trompe peut-être ?

[banban54]

bonjour

Même quelques millièmes de secondes seront les bienvenus...

Code :

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

i := i and $ff;      // revient à un genre de modulo

semble 10 à 15 fois plus rapide que:

Code :

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

i:=round(256*(i+2048)/4096);

à+

[Paul TOTH]

bonjour

Code :

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

i := i and $ff;      // revient à un genre de modulo

semble 10 à 15 fois plus rapide que:

Code :

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

i:=round(256*(i+2048)/4096);

à+

oui mais c'est pas la même chose

2000 and $ff = 208
(2000 + 2048) div 16 = 253

[banban54]

bonjour

Il faut que je fasse la conversion de I pour que l'étendue soit 0..255.

il est vrai que les résultats ne sont pas les mêmes, mais à la vue de l'ennoncé il sont tous les deux justes.

par contre si l'étendue est modifiée parce que les valeurs (comme dans son exemple) ne sont représentatives que entre 0 et 255 alors...
255 and $ff = 255
(255+ 2048) div 16 = 137

attendons le besoin de Pedro

à+

[ShaiLeTroll]

J'avais déjà, eu à faire ce genre de manip, corriger un fichier texte,

pré-requis, le fichier est en format windows #13#10 ...

donc à chaque lecture (ReadLn), je cumulais la taille de la chaine lu + 2, et si la ligne était problématique, j'ajoutais dans une TList, le couple nouvelle valeur et offsets (position, longueur ...), ensuite, je recopiais le fichier, en passant par un BlockRead, en sautant de bloc en bloc, ne me préoccuppant que des bloc problématique ... bon, si tu as un fichier de 1Go, il faut penser à avoir la place pour le second fichier sur le DD, qui prendra la place du premier ...

[droggo]

Kio,

Code :

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

1
2
 
ReadLn(f1,x,y,z,i);

Ca marche ça?? Alors là j'en apprends une belle

C'est pourtant du Pascal basique.

Pour la lecture du fichier, je préfère toujours la lecture ligne à ligne, ce qui évite de dépendre de la taille du fichier pour la mémoire utilisée.

Côté vitesse, si j'ai bien compris, pas vraiment à s'inquiéter pour une opération à ne faire qu'une fois.

il est vrai que les résultats ne sont pas les mêmes, mais à la vue de l'ennoncé il sont tous les deux justes.

On peut tout de même prévoir que le résultat du calcul doit être proportionnel à la valeur d'origine

[TicTacToe]

Je pense que Pedro veut que sa nouvelle étendue soit dans les même proportions que son étendue initiale.

Sinon, coté pinaille, mais je suis certains que les bricoleurs trouveront encore mieux, on peut faire

Code :

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

i := (i + 2048) shr 4

addition à cause du négatif, sinon un 'or' aurait fait l'affaire

mais je doute que ca améliore quoi que ce soit, comparé au temps de lecture disque + convserion string->entier->string...

[Pedro]

Merci à tous pour vos réponses

C'est pourtant du Pascal basique.

Oui bon ça va hein

par contre si l'étendue est modifiée parce que les valeurs (comme dans son exemple) ne sont représentatives que entre 0 et 255 alors...
255 and $ff = 255
(255+ 2048) div 16 = 137

attendons le besoin de Pedro

Non c'est toujours la même étendue de départ et d'arrivée Plus précisement, la valeur d'entrée de I est signée 12 bits et doit être convertie en non signé 8 bits en sortie (évidemment, il y a une déperdition de la précision de la valeur mais ça ne pose pas de problème)

Pour la lecture du fichier, je préfère toujours la lecture ligne à ligne, ce qui évite de dépendre de la taille du fichier pour la mémoire utilisée.

Oui c'est ce que je fais Tu penses bien que je n'ai même pas essayé de tout charger en mémoire avec un fichier d'une telle taille
Sinon, j'avais pensé aussi à faire comme le fait ShaiLeTroll mais le problème reste entier: Ca prend trop de ressource Et puis cela revient à parcourir les données 2 fois...

Côté vitesse, si j'ai bien compris, pas vraiment à s'inquiéter pour une opération à ne faire qu'une fois.

Effectivement mais là j'ai plusieurs millions de lignes... C'est pour ça que le moindre millième de seconde est bon à prendre

Je vais de ce pas faire ces essais maintenant que je suis chez moi

Je pense que Pedro veut que sa nouvelle étendue soit dans les même proportions que son étendue initiale.

Exactement cher ami

[Pedro]

Bon voici les résultats sur 10000 lignes:

Méthode de conversion:

Code :

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

1
2
3
4
5
 
function TForm1.ConvertValue(const Value: integer): integer;
begin
  Result := Trunc(256 * (Value + 2048) / 4096)
end;

Ma méthode:

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
 
function TForm1.Methode1(const s: string): string;
begin
  Tmp.DelimitedText := s;
  Tmp.Strings[3] := IntToStr(ConvertValue(StrToInt(Tmp.Strings[3])));
  Result := Tmp.DelimitedText;
end;
 
...
var TempsDebut1, TempsDebut2, TempsFin1, TempsFin2: Cardinal;
    fIn, fOut: TextFile;
    s: string;
    a, b, c: Single;
    i: integer;
begin
    Tmp := TStringList.Create;
    try
      Tmp.Delimiter := ' ';
      //Méthode 1
      TempsDebut1 := GetTickCount;
      AssignFile(fIn, Fich.Text);
      AssignFile(FOut, Fich.Text + ' Converti.txt');
      Reset(fIn);
      Rewrite(fOut);
      while not Eof(fIn) do
      begin
        ReadLn(fIn, s);
        WriteLn(fOut, Methode1(s));
      end;
      CloseFile(fIn);
      CloseFile(FOut);
      TempsFin1 := GetTickCount;
    finally
      Tmp.Free;
    end;
end;

avec Tmp: TStringList

Méthode de Paul TOTH :

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
 
var TempsDebut1, TempsDebut2, TempsFin1, TempsFin2: Cardinal;
    fIn, fOut: TextFile;
    s: string;
    a, b, c: Single;
    i: integer;
begin
    TempsDebut2 := GetTickCount;
    AssignFile(fIn, Fich.Text);
    AssignFile(FOut, Fich.Text + ' Converti2.txt');
    Reset(fIn);
    Rewrite(fOut);
    while not Eof(fIn) do
    begin
      ReadLn(fIn, a, b, c, i);
      i := ConvertValue(i);
      WriteLn(fOut, Format(c_Out, [a, b, c, i]));
    end;
    CloseFile(fIn);
    CloseFile(FOut);
    TempsFin2 := GetTickCount;
end;

J'ai du ajouter le Format avec

Code :

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

1
2
 
  c_Out = '%.5f %.5f %.5f %u';

parce que sinon, ça sort en format ingénieur (XXXE+XXX) sans espaces Ou alors y a encore des trucs que je sais pas sur ReadLn et WriteLn

Les résultats

Ma méthode : 63 ms
La méthode de Paul : 47 ms Presque 30% de temps de gagné

Je m'attendais à un écart plus grand quand même Au vu de ma sale méthode

Je suis par contre certain que l'on peut encore améliorer ces données. En particulier sur le calcul

[Paul TOTH]

oui tu ignores une chose sur le WriteLn

tu peux préciser le formatage comme ceci par exemple

Code :

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

1
2
 
WriteLn(x:0:2,' ',y:0:2,' ',z:0:2,' ',i);

[Pedro]

oui tu ignores une chose sur le WriteLn

Eh ben j'aurais pas perdu ma journée moi

Merci Paul

[EDIT]
Aucun changement de rapidité: ça reste à 47 ms... Par contre, c'est bon à savoir

[Paul TOTH]

encore une petite chose que tu dois pouvoir utiliser...SetTextBuf()

la taille du buffer par défaut est de 128 bytes, une lecture par bloques de 4K peut rendre les choses plus rapides.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
var
 f:TextFile;
 b:array[0..4095] of char; // ou autre taille...
begin
 AssignFile(f,'fichier.dat');
 SetTextBuf(f,b);
 Reset(f);
 while not eof(f) do begin
  ReadLn(f,x,y,z,i);
 ...
 end;
end;

[TicTacToe]

J'ai fais un petit tests et effectivement, ce que je disais il y a quelques post semble être vrai.

La gestion avec un TStringList et nettement plus rapide qu'avec une lecture séquentielle ligne à ligne.

un petit prog pour le montrer (j'ai repris la dernière méthode de Paul Toth pour la comparaison, c'est la 'méthode2'):
http://tictactoe.developpez.com/temp/pedro.zip

pour un fichier de 1 500 000 lignes, qui a un poids d'environs 54Mo,
le gain est environs 2.5 à 3 fois plus rapide (environs 2.3 sec contre 7 sec sur ma machine...)

si les fichiers font 3 000 000 de lignes (donc largement au dessus des prévisions de taille de fichier), cela fait 110Mo à prendre en mémoire... c'est pas le Pérou non plus

Après le tout est de savoir à quoi on donne la priorité, la performance mémoire ou la performance vitesse (très souvent inversement proportionelle d'ailleurs...)