Discussion :

[golgauth]

Bonjour à tous,

Voilà, je travaille pour l'heure sur l'optimisation de morceaux de programme.
Et j'obtiens des resultats assez surprenants, donc si un maitre du delphi peut me renseigner sur le pourquoi de la chose...

Je vous expose la chose :

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
procedure TWeather.Load(var f_temp:text; pheno: TRPhenoInfos; tempfit: integer);
var
  i, j : integer;
  doy1, year1, codestation : integer;
  temp1,temp2,temp3,lat1:double;
  nb_days:integer;
 
  wd : TRWeatherDay;
  y_idx : integer;
 
  a_arr : vectdays;
 
  t : TDateTime;
 
  vec : array[1..50] of ^TRWeatherDay;
 
begin
 
  LogIt('START Reading...'); t := Now;
 
  reset(f_temp);
  readln(f_temp); //skip header
 
  Self.SetSize(pheno.nb_obs);
 
  for j:=1 to pheno.nb_obs do
  begin
    y_idx := j-1;
 
    repeat readln(f_temp, codestation, lat1, year1, doy1, temp1,temp2,temp3)
    until (((codestation = pheno.Tabpheno[j].station) and (year1 >= pheno.Tabpheno[j].year)) or (codestation = 0));
 
    if (codestation = 0) then
        raise Exception.create('Station not found or stations in wrong order!');
 
 
    Self.year[y_idx] := TWeatherYear.Create(year1, y_idx, Self.selfPtr);
 
    wd := CreateWeatherDay(codestation, lat1, year1, doy1, temp1, temp2, temp3);
 
    if (tempfit = 1) then wd._tmu := wd._tmp
    else if (tempfit = 2) then wd._tmu := wd._tmn
    else if (tempfit = 3) then wd._tmu := wd._tmx;
 
    Self.year[y_idx].SetDay(doy1, wd);
 
    nb_days := Self.year[y_idx].numDays; //GetNbDays(v._yea);
    for i:=2 to nb_days do
    begin
 
      readln(f_temp, codestation, lat1, year1, doy1, temp1, temp2, temp3);
      if (codestation = 0) then
        raise Exception.create('Unexpected EOF found > the year could not be read entirely !');
 
      wd := CreateWeatherDay(codestation, lat1, year1, doy1, temp1, temp2, temp3);
 
      if (tempfit = 1) then wd._tmu := wd._tmp
      else if (tempfit = 2) then wd._tmu := wd._tmn
      else if (tempfit = 3) then wd._tmu := wd._tmx;
 
      Self.year[y_idx].SetDay(doy1, wd);
 
 
    end;
 
  end;
 
  LogIt('END Reading...' + FormatDateTime('ss.zzz', Now - t));
  new (vec[1]);
 
end;

Dans ce code, la ligne "new (vec[1]);" est, théoriquement, parfaitement inutile hors temps d'execution de la fonction :
* ~6 sec si je commente "new (vec[1]);"
* ~1.5 sec, si je mets le taille du tableau "vec" à 5000
* ~0.71 sce, avec le code soumis ci-dessus.

Y a t'il une raison à cela (je suppose que oui), mais j'ai besoin de vos conseils.
Merci pour votre aide.

PS : Je suis aussi preneur si vous avez des idees, a-priori, d'amelioration de mon algo.

[ShaiLeTroll]

C'est mieux en Français

Quel Delphi ?
V7 ? FastMM ?
A partir de D2007, FastMM est inclu, mais cela impacte surtout les chaines et les allocations par New (le tas) mais pas les variables de la pile (comme ton array)
Tu devrais activer "ReportMemoryLeaksOnShutdown", tu dois avoir des fuites un peu partout avec du code si Etrange !

ce sujet RAM non utilisée va te passionner !
Cela va te donner pas mal d'info sur la mémoire ! l'allocation et la libération !



Vec n'est pas du tout utilisé !
Retire le New ET la déclaration, dis nous le temps !

Si tu laisse l'étrange New, cela alloue un pointeur non libéré, c'est vrai que c'est moche !
Si retire juste l'étrange New, tu n'aurais pas un Avertissement "Variable non utilisée" donc en théorie, je crois qu'elle n'est pas alloué sur la pile !

Tu devrais mesurer le temps à l'extérieur de la fonction et à l'intérieur (ton cas actuel)

Car, à part la libération de Vec lors du dernier "end", la présence de l'étrange New ne devrait pas changer grand chose !

Utilise QueryPerformance Counter\Frequency, c'est plus fiable que Now() !

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
procedure GetBeginTime(var Value: Int64);
begin
   QueryPerformanceCounter(Value);
end;
 
function ElapsedTime(var BeginTime: Int64): Cardinal;
var
   EndTime, TickPerSec: Int64;
begin
   QueryPerformanceCounter(EndTime);
   QueryPerformanceFrequency(TickPerSec);
   Result := Round((EndTime - BeginTime) / TickPerSec * 1000);
end;
 
function FormatMS(MilliSecondes: Cardinal): string;
var
  Hour, Min, Sec: Cardinal;
begin
  Hour := MilliSecondes div 3600000;
  MilliSecondes := MilliSecondes mod 3600000;
  Min := MilliSecondes div 60000;
  MilliSecondes := MilliSecondes mod 60000;
  Sec := MilliSecondes div 1000;
  MilliSecondes := MilliSecondes mod 1000;
  Result := Format('%.2d:%.2d:%.2d:%.3d', [Hour, Min, Sec, MilliSecondes]);
end;

[golgauth]

Merci beaucoup pour toutes ces infos.

Le temps en virant la ligne qui ne sert a rien est déja mentionné : 6sec.

J'ai deja intégré FastMM avec stack trace et tout. Et en effet j'ai pas mal de fuites connues que je n'ai pas encore pris le temps de corriger.
Tu penses que ca expliquerait les delires de perfs dans mon code ?

Parce qu'en effet "l'etrange new" ne sert strictement à rien : comment on peut passer de quelques fuites memoires (ma ram n'est pas tant solicitée que ca), à des comportements aussi louches ?

[ShaiLeTroll]

Le temps en virant la ligne qui ne sert a rien est déja mentionné : 6sec.

en supprimant le New, oui tu l'as déjà donné, moi je te parle de retirer vec : array[1..50] of ^TRWeatherDay; qui ne sert strictement à rien puisque pas utiliser (sauf ce étrange new)

[golgauth]

Oui, alors j'ai effectivement viré la declaration (array[0..50]...) et ca donne 6 secondes. Idem...

Je jete un coup d'oeil a tes lien.

Thanks a lot again
Regards

Edit : Desolé, j'ai oublié de répondre à tes questions :
- Je suis sous delphi 2010

[golgauth]

Apres reflexion, est-ce que la presence de cette ligne inutile ne serait-elle pas responsable d'une optimisation differente (meilleure) par le compilateur delphi. Je ne suis pas tres au fait de comment voir ca via le code asm generé.
Je ragarde comment visualiser les codes asm avec et sans la ligne etrange...

[Franck SORIANO]

En travaillant avec des fichiers, il faut t'attendre à ce que les performances soient aléatoires.
Tu dépends énormément de l'état de la machine : Etat des caches disques, ce que fais Windows en tâche de fond... De plus, à chaque fois que ton appli fait une E/S tu donnes une opportunité à Windows de prendre la main pour faire autre chose...

Lorsque tu exécutes ton appli une première fois à froid, Windows doit lire le fichier depuis le disque. Mais si tu recommences juste derrière, le fichier est présent en cache et la lecture est beaucoup plus rapide.
Pour mesurer tes temps, tu as bien lancé plusieur fois le même traitement dans les mêmes conditions pour identifier le temps le plus caractéristique ?

Si le fichier n'est pas trop volumineux, tu ferais mieux de le charger intégralement en mémoire au début du traitement (par exemple avec un TStringList), puis analyser le contenu toi même.
Les performances seront bien meilleures.

[golgauth]

Salut et merci pour vos reponses,

Pour mesurer tes temps, tu as bien lancé plusieur fois le même traitement dans les mêmes conditions pour identifier le temps le plus caractéristique ?

Oui.

Si le fichier n'est pas trop volumineux, tu ferais mieux de le charger intégralement en mémoire au début du traitement (par exemple avec un TStringList), puis analyser le contenu toi même.

Le soucis est que je manipule, potentiellement plusieurs fichiers (en multi-thread) pouvant atteindre 400000 lignes. Je pense que c'est un peu violent pour des StringLists...

De plus mes resultats ne sont pas du tout aléatoires : j'obtiens toujours la meme choses...