Discussion :

[Art19]

A titre pratique, tu peux utiliser IndexOf poour déterminer si une chaîne de caractères se trouve déjà dans la TStringList. Remarque que cela n'accélérera pas ton traitement, mais le code est plus simple.

ok merci, c'est vrai que la j'ai reinvente la roue..

Cela ne résoud pas le problème de la taille des données.

tu as une solution meilleure que de lire une ligne l'une apres l'autre? (je prend)

[Art19]

j'ai mieux encore:

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
  for i := 0 to fichiers.Count-1 do begin
 
    lignes.Clear();
 
    AssignFile( fich, fichiers[i] );
    Reset( fich );
 
    while not Eof(fich) do begin
       ReadLn( fich, s );
 
       if lignes.IndexOf( s ) > -1 then begin
        memo1.Lines.Add( 'le fichier '+fichiers[i]+' contient un ou plusieurs doublon(s)' );
        break;
       end;
 
       lignes.Add(s);
 
    end;

a quoi sert ton try?

[Gilbert Geyer]

A Art19 :

Merci pour le code finalement retenu ... mais en le comparant à celui qui est joint à ton message du 25/05/2007, 20h25 on constate que c'est exactement le même qu'au début de la discussion et que le problème initial n'est pas vraiment résolu.

...... donc on peut continuer à chercher les diverses possibilités d'optimisation.

Bon c'est confirmé que "dès qu'il y a un doublon je sors de ma boucle"

Par contre pour continuer à optimiser, vu qu"en pratique c'est quand meme tres lent!" ce serait sympa de nous en dire un peu plus sur la structure-probable-des-fichiers-concernés par la recherche des 1ers doublouns cela nous permettrait au moins de pouvoir créer un fichier-de-tests qui correspondrait le mieux aux fichiers concernés car à-taille-égale un fichier dont les lignes font seulement 7 caractères maxi cela donne X-mille-lignes alors que si en réalité ce même fichier était caractérisé par des lignes de longueur comprise aléatoirement entre 0 et 280 caractères maxi cela donnerait grossomodo un fichier de seulement ((X-Mille-lignes) fois 7/280) ... et comme les lenteurs diminuent surtout en fonction du nombre de lignes cela permettrait de mieux faire coller les tests à la réalité à la fois pour ce qui est de la quantité-minimale-d'infos à placer en mémoire et pour ce qui est des vitesses.

[ShaiLeTroll]

De plus, nous sommes tous partis pour code via TStream ou API Windows pour gérer des fichiers de plus de 2Go ... et si le AssignFile suffit c'est que c'est moins de 2Go ...

[Art19]

voila le type de fichiers:

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
10/03/05,17:04,0.87,0.87,0.87,0.87,1
10/04/05,17:04,0.87,0.87,0.87,0.87,1
10/05/05,16:04,0.86,0.86,0.86,0.86,1
10/06/05,16:04,0.86,0.86,0.86,0.86,1
10/07/05,16:03,0.87,0.87,0.87,0.87,1
10/10/05,16:04,0.87,0.87,0.87,0.87,1
10/11/05,16:03,0.86,0.86,0.86,0.86,1
10/12/05,16:04,0.87,0.87,0.87,0.87,1
10/13/05,16:04,0.86,0.86,0.86,0.86,1
10/14/05,16:03,0.86,0.86,0.86,0.86,1
10/17/05,16:05,0.86,0.86,0.86,0.86,1
10/18/05,16:05,0.86,0.86,0.86,0.86,1
10/19/05,16:05,0.86,0.86,0.86,0.86,1
10/20/05,16:05,0.86,0.86,0.86,0.86,1
10/21/05,16:03,0.86,0.86,0.86,0.86,1
10/24/05,16:05,0.86,0.86,0.86,0.86,1
10/25/05,16:04,0.86,0.86,0.86,0.86,1
10/26/05,16:04,0.87,0.87,0.87,0.87,1
10/27/05,16:04,0.87,0.87,0.87,0.87,1
10/28/05,16:04,0.86,0.86,0.86,0.86,1

Le AssignFile ne marche pas au dessus de 2Go?

[Gilbert Geyer]

Bon on avance :

10/10/05,16:04,0.87,0.87,0.87,0.87,1

... et peut on en déduire que la longueur de chaque chaine est non seulement constante dans un même fichier mais égale à la précédente dans tous les fichiers à ausculter ?

- "AssignFile ne marche pas au dessus de 2Go?" : Sur ce point je fais confiance à ShailLeTroll n'ayant pas trouvé immédiatement dans l'aide ... mais la pratique révèle en plus qu'il y a pas mal de problèmes de lenteur qui peuvent être améliorés avec un FileStream associé à un buffer de taille appropriée pour aspirer en mémoire le minimum de données utiles, donc faut pas s'en priver.

[ShaiLeTroll]

Bon, il semble que j'arrive à générer un fichier de 4Go, ce qui est la limite c'est sur car c'est géré sur des cardinals et que les fonctions liés au file pascal ne gère pas la partie High dans SetFilePointer, suffit de voir le code du Seek dans fichier pascal

Code :

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

1
2
3
4
5
6
7
PUSH     FILE_BEGIN    // pass dwMoveMethod
        MOV      EAX,[ECX].TFileRec.RecSize
        MUL      EDX
        PUSH     0           // pass lpDistanceToMoveHigh
        PUSH     EAX           // pass lDistanceToMove
        PUSH     [ECX].TFileRec.Handle   // pass hFile
        CALL     SetFilePointer          // get current position

Sinon ton fichier, si il est TOUJOURS comme cela, on pourrait un fichier binaire avec un enregistrement de taille 36+2 (si toujours CR+LF), ainsi la lecture serait plus rapide, ... cela me fait penser aux des fichiers EURUSD de FOREXMATRIX, un projet d'un membre du forum pour la gestion des taux de change ...

Donc oui, ton fichier pourrait-être bien plus efficacement en position fixe qu'en fichier texte en ligne ...

[banban54]

bonjour

si tous les fichiers ont la même structure, et que les enregistrements sont bien triés par date/heure, il n'y a plus besoins de Tstringlist ou autre, il suffit de comparer par rapport à la ligne précédente!!

mais ça doit être trop simple..

à plus

[Art19]

Les fichiers suivent toujours plus ou moins ce modele mais le nombre de caracteres par ligne peut varier. Il ne faut avoir aucun a priori sur la forme du fichier. Tout ce qu'on sait c'est qu'on va avoir un truc du type:

Code :

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

1
2
3
4
5
 
date, heure, champ1, champ2, ..., champN
date, heure, champ1, champ2, ..., champN
...
date, heure, champ1, champ2, ..., champN

[Art19]

si tous les fichiers ont la même structure, et que les enregistrements sont bien triés par date/heure, il n'y a plus besoins de Tstringlist ou autre, il suffit de comparer par rapport à la ligne précédente!!

mais ça doit être trop simple..

oui car les fichiers ne sont pas tries justement

[e-ric]

a quoi sert ton try?

à garantir la fermeture du fichier (CloseFile)

cdlt

[ShaiLeTroll]

Je suis en train de générer un gros fichier, j'ai écrit 10*066*330*800 octets en écriture simple, je n'ai pas testé si il est possible de lire tout cela mais semble que cela fonctionne avec une lecture normale, la limite des 4Go ne concerne que le SEEK

effectivement le try est mal placé

Code :

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

1
2
3
4
5
6
7
8
9
    AssignFile( fich, fichiers[i]);
    try
      Reset( fich );
      while not Eof(fich) do 
      //....
      end;
    finally
      CloseFile(fich);
    end;

le CloseFile n'est pas le pendant à AssignFile mais à Reset, Rewrite ou Append

Code :

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

1
2
3
4
5
6
7
8
9
    AssignFile( fich, fichiers[i]);
    Reset( fich );
    try
      while not Eof(fich) do 
      //....
      end;
    finally
      CloseFile(fich);
    end;

[Gilbert Geyer]

Code :

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

date, heure, champ1, champ2, ..., champN

... et dans "champ1, champ2, ..., champN" a-t-on une idée sur la valeur max du "N" dans champN" ???
... En bref, Nmax c'est un Byte, un ShortInt ou davantage ??

[Art19]

N est le meme pour tout le fichier mais il peut varier d'un fichier a un autre. Le Nmax doit etre < 10

[ShaiLeTroll]

Il se pourrait que la limite des 4Go concerne le EOF du fichier binaire, pour le fichier texte, je n'arrive pas à comprendre l'ASM pour savoir si il y aurait aussi cette limite, je n'ai jamais utilisé ReadLn pour de si gros fichier mais BlockRead (petit fichier) ou ReadFile (gros fichier)

Si le fichier est variable, la considération de la longueur de chaine n'est plus importante ....

[Art19]

oui mais avec ReadFile tu load quelle taille?

[Gilbert Geyer]

Si "Le Nmax doit etre < 10" on peut en déduire quand même une longueur maxi de chaine pour un 1er fichier-de-tests et un 2ème fichier-de-tests avec Nmini=1. Non ? Histoire de pouvoir faire des tests aux conditions-limites.

[ShaiLeTroll]

oui mais avec ReadFile tu load quelle taille?

ReadFile c'est avec un Int64, donc cela dépasse le Yota Octets ... (10^24)
Virtuellement infini ... mais aura tu plus de 4Go ?
Pour info ReadFile c'est l'API Windows, par habitude j'utilise SysUtils.FileRead qui n'est qu'une encapsulation de Windows.ReadFile
De plus le TFileStream utilise SysUtils.FileRead

[Gilbert Geyer]

Au fait Art19, dans ton message du 25/05/2007, 19h48 tu précises que "gros fichier" = "plusieurs Giga" ... Giga c'est clair, mais "plusieurs" c'est combien au maxi, car "plusieurs" cela commence à 2 mais on ne sait pas où cela s'arrête ???

Tiens ShailLeTroll a été plus rapide que moi à poser la même question.

[Art19]

max 10Go mais c'est pure precaution parce que je ne rencontre pas plus que 2Go pour l'instant