Discussion :

[Invité]

Bonjour,

j'ai installé ce matin une version Trial XE5 puisque mon établissement scolaire propose de m'offrir une Architect Education... et comme je consacre toujours quelques jours pendant mes vacances à faire des comparatifs, je suis parti d'un petit projet Lazarus qui a pour objet de charger 10 000 enregistrements dans une table SQLite mémoire puis de les afficher dans une dbGrid ou dGrid (pour FMX). La table contient 3 champs : un integer, un varchar(20), un blob pour y placer une vignette.png 16*16.

En plus de Lazarus, j'ai réalisé le projet

• en VCL avec FireDac, FDquery et DataSource sur une dbGrid histoire de me remémorer l'interface de l'IDE
• en FMX avec cible Windows 32 également avec FireDac, FDquery, BindSourceDB et Grid.
• et en WinDev 18 sur cibles Windows 32 et 64 bits

Je pense que j'ai perdu la main en Delphi. Le projet pour charger les 10000 lignes met plus de 15 secondes dans les 2 cas et 1 seconde en Lazarus (et 5 à 7 secondes en WinDev suivant les essais exe32 sur 32 bits, exe32 sur 64 bits ou exe64 sur 64 bits)... évidemment sur la même machine.

En Delphi, le problème de la lenteur vient de ma manière de charger les vignettes dans le MemoryStream.... Si je charge une fois le MemoryStream, puis les 10 000 enregistrements donc les 10 000 Blobs avec celui-ci, le temps de remplissage descend à 2 secondes donc à peu près identique à celui de Lazarus (sauf qu'en Lazarus pour le même temps je vide et remplis mon Stream 10 000 fois).
En Lazarus

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
procedure TForm1.Button1Click(Sender: TObject);
//imgSrc : TImage
var
   sREQcreate, strDiff : String;
   startTime, endTime  : Tdatetime;
   streamTMP  : TMemoryStream;
   iLoc       : Integer;
 
   bOK : Boolean;
begin
  bOK := True;
  startTime := getTickCount;
  with SQLite3Connection1 do
    if not connected then connected := True;
  sREQcreate := 'CREATE TABLE test2013 ( teid INTEGER PRIMARY KEY, tenom VARCHAR(20), teimage BLOB);';
  with SQLQuery1 do try
    SQL.Text := sREQcreate;
    ExecSQL;
    Close;
  except
   Close;
   bOK := False;
   Showmessage('Oups 1');
  end;
  if bOK then try
    streamTMP := TMemoryStream.Create;
    for iLoc := 1 to 10000 do
      with SQLQuery1 do begin
        streamTMP.Size := 0;
        imgSrc.Picture.SaveToStream(streamTMP);
        with SQL, Params do begin
          Clear;
          SQL.Text := 'INSERT INTO test2013 '+
                      '(teid, tenom, teimage) '+
                      'VALUES ' +
                      '(:paID, :paNOM, :paIMAGE);';
                      ParamByName('paID').AsInteger := iLoc;
                      ParamByName('paNOM').AsString := 'TEST'+ IntToStr(iLoc);
                      ParamByName('paIMAGE').LoadFromStream(streamTMP, ftBlob);
        end;
        try
          ExecSQL;
          Close;
        except
          Close;
          bOK := False;
          break;
        end;
      end;
    endTime := getTickCount - startTime;
    strDiff := FloatToStr(endTime/1000);
    if bOK  then
      showmessage(strDiff)
    else
      Showmessage('Oups 2');
  finally
    streamTMP.Free;
  end;
end;

En FMX, le code est quasiment identique et visiblement mal optimisé

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
procedure TForm1.Button1Click(Sender: TObject);
//  imgSrc: TImage;
var
   sREQcreate : String;
   streamTMP  : TMemoryStream;
   iLoc : integer;
   StopWatch: TStopWatch;
   bOK : Boolean;
 
 begin
   bOK := True;
   StopWatch := TStopWatch.Create;
   StopWatch.Start;
 
   with FDconnection1 do
     if not connected then connected := True;
   sREQcreate := 'CREATE TABLE test2013 (teid INTEGER PRIMARY KEY, tenom VARCHAR(20), teimage BLOB);';
   with FDQuery1 do try
     SQL.Text := sREQcreate;
     ExecSQL;
     Close;
   except
     Close;
     bOK := False;
     Showmessage('Oups 1');
   end;
 
   if bOK then try
     streamTMP := TMemoryStream.Create;
     for iLoc := 1 to 10000 do  begin
       streamTMP.Size := 0;
       imgSrc.Bitmap.SaveToStream(streamTMP);
       with FDQuery1 do begin
         with SQL, Params do begin
           Clear;
           SQL.Text := 'INSERT INTO test2013 '+
                       '(teid, tenom, teimage) '+
                       'VALUES ' +
                       '(:paID, :paNOM, :paIMAGE);';
           ParamByName('paID').AsInteger := iLoc;
           ParamByName('paNOM').AsString := 'TEST'+ IntToStr(iLoc);
           ParamByName('paIMAGE').LoadFromStream(streamTMP, ftBlob);
         end;
         try
           ExecSQL;
           Close;
         except
           Close;
           bOK := False;
           break;
         end;
       end;
     end;
     stopWatch.Stop;
     if bOK  then
       showmessage(FloatToStr(stopWatch.ElapsedMilliseconds/1000))
     else
        Showmessage('Oups 2');
   finally
      streamTMP.Free;
   end;
 end;

Enfin là n'est pas le problème pour l'instant.... mais va le devenir rapidement .

J'ai un problème en FMX (et son LiveBindings) que je ne rencontre pas en VCL (avec son DataSource). On peut le constater sur l'image ci-dessous. Je charge les 10000 enregistrements dans la table. Le LiveBindings n'en affiche que 200. Si je clique sur la 200ème ligne, on passe instantanément à 300. Si je reclique sur la 300ème ligne, il ne se passe rien. (ie on reste à 300)... Et si avec le DbNavigateur je clique sur le bouton [>>], j'arrive bien sur la ligne 10000. Mais la remontée vers la ligne 1 est tout aussi impossible : une tranche de 100 à 200, puis plus rien. J'ai regardé dans les "réglages"... sans succès. J'ai regardé sur Internet, pas mieux. Donc help ! où est le problème ?



Si quelqu'un a l'occasion de se pencher sur mon code... Voici le projet complet FMX. Il est forcément bancal quelque part au niveau "LiveBindings" mais je manque de Doc. Pas vu sur Internet non plus, il y a un (le) livre à acheter sur FMX ? Je sais... Il y a des vidéos... Mais je n'apprends pas correctement avec ce support.... J'ai besoin d'un livre qui "va à ma vitesse", que je peux annoter...
D'avance merci.
Cordialement. Gilles

PS :

• Même exercice demain entre C++Builder FMX et C++/Qt... Il vaut mieux débrancher... entre Pascal et C++.
• Ci-joint l'exécutable Laz32 du même projet [source dispo sur le forum lazarus] qui met en évidence -c'est le moins qu'on puisse dire- la différence de vitesse d'exécution des 2 codes.

[SergioMaster]

Bonjour ,

je ne donnerais pas un avis d'expert , mais juste celui d'un testeur guère plus avancé .
- la lenteur , dans mes essais , je ne l'ai pas constaté , mais pas sur des tests aussi importants , donc je ne m'avancerai pas

par contre sur le problème (saut de 200 à 300 etc... ) le problème vient de Firedac (enfin d'un option qu'il faut mettre FetchOptions.LiveWindowParanoic to True. ) et non des livebindings sensu stricto . Je pense avoir reporté ce problème dans ce forum .

[skywaukers]

Bonjour,

Avez- vous soumis votre problème à Embarcadero ? Qu'en disent-ils ?

(assez illisible votre code, mais je suppose que parce que vite fait. Même si cela n'a rien à voir avec le sujet, les with : ).

Et bon ok c'est pour vous passer le temps, mais je ne pense pas que la méthode soit bien choisie pour un besoin d'exécution de 10000 requettes SQL, il doit bien y avoir une possibilité d'exécuter des scripts de façon à ne faire le execSQL qu'une fois.
Après la comparaison avec Lazarus, qui doit avoir un composant spécifique pour SQLLite, et Firedac me semble difficile à faire, vu que Firedac s'appui sur la même base de composants pour n'importe quelle base de données. Il est certains qu'un code écrit explicitement pour une base de données va être optimisé aux petits oignons pour profiter au max des possibilités de la BDD. L'inconvénient c'est qu'il sera alors lié à ce moteur et dès qu'on aura à travailler avec un autre, il faudra un autre composant, d'autres méthodes, ... Bref le code sera moins portable vers d'autres bases de données.

Pour la pagination par contre, je pense que là il y a effectivement un gros bug Il faudrait le signaler à Embarcadero.

@++
Dany

[skywaukers]

oups, grillé

la lenteur y est clairement : 7 secondes chez moi.

Par contre même en cochant FetchOptions.LiveWindowParanoic le problème reste chez moi (je l'ai coché sur le FDConnection et sur le FDQuery2.
Tu es sur qu'il n'y a que cela à faire ? (en tout cas là pour mi le comportement devrait être par défaut, ou alors cela devrait être bien documenté).

@++
Dany

[SergioMaster]

Re,

N'ayant pas XE5 ni SQLLite, et ne voulant pas les installer , j'ai réécrit avec XE4+Firebird puis recopier le code .(pour la lenteur du coup c'est le pompon
mais le ExecSQl;Close; y est pour beaucoup )
Sinon effectivement il y a blocage a 200 même après un Fetchall juste après le Open .
@Skywaukers le FetchOptions.LiveWindowParanoic était sur un autre point
@Selzig merci pour le joli cadeau de vacances

je vais retrouver le truc , sinon bien sur il y a EDN
et : as-tu essayé avec DBExpress ? dans mes tentatives passées je faisais toujours le test DBExpress/Firedac , en général le premier fonctionnait le second était problématique jusqu'à la découverte de l'option que Dmitry sortait de son chapeau

[Invité]

Alors plus précisément :

pour la lenteur du coup c'est le pompon
mais le ExecSQl;Close;[...]

Chez moi ce sont les Streams qui posent problèmes. Avec une seule création et un seul remplissage du Stream, puis 10000 enregistrements de ce Stream, le temps de création de la table est inférieur à 2 secondes. Donc RAS de ce côté.

DBExpress/Firedac , en général le premier fonctionnait le second était problématique jusqu'à la découverte de l'option que Dmitry sortait de son chapeau

• Même du temps de Delphi Win 32, je n'ai jamais assimilé la complexité de dbExpress
• Et qu'y a-t-il dans le chapeau de Dmitry ?

Cordialement. Gilles

[free07]

Alors plus précisément :


Chez moi ce sont les Streams qui posent problèmes. Avec une seule création et un seul remplissage du Stream, puis 10000 enregistrements de ce Stream, le temps de création de la table est inférieur à 2 secondes. Donc RAS de ce côté.

Tiens, cela explique peut être les relatives lenteurs que j'ai constaté aussi avec DBExpress et SQLite, je crée un Stream pour chaque lecture de blob...
Merci pour la piste , je vérifierai cela dès que j'aurais le temps.

[Invité]

Bonjour,

Merci pour votre aide.

@SergioMaster : Désolé, je ne lis pas de manière réellement suivie le forum Delphi. Et dans le forum actuel je n'ai pas jamais trouvé LE champ de recherche. La notation des discussions me semble beaucoup moins efficace qu'un champ de recherche comme on trouve par exemple sur le forum anglais de Lazarus.

@Dany : Désolé pour les with, je factorise, j'aime bien... Déformation de profs de maths (la facto, c bô !)...

Pour le reste, j'ai abandonné une fois FMX et je n'ai pas l'intention de baisser les bras encore une fois... J'essaye d'identifier le problème...

1. Cela marche parfaitement en VCL avec les même composants jusqu'au DataSet... Ce qui exclut à mon avis la responsabilité de FireDac intrinsèquement sauf peut-être pour son "interface livebindings" s'il a une part là-dedans. En VCL, j'ai ensuite un classique DataSource et une dbGrid : Hormis là aussi, une lenteur certaine sur les Streams, RAS.

2. en FMX, TGrid, TStringgrid : même problème des "200". J'ai donc supposé que le problème était le liveBindings. Mais je vais savoir rapidement... Je vais créer un TStringGrid de 3 colonnes et 10000 lignes... Si cela fonctionne, cela éliminera un problème de mécanisme interne de la TstringGrid. [Testé : RAS Ajout 12:22]

Zut : comment on ajoute des columns à la Tstringgrid en FMX?
Bon officiellement aujourd'hui, je fais la même chose en C++... Alors là, Dany, je crois que je ne vais pas mettre mon code en ligne... C'est du grand n'importe quoi... Mais ce qui me rassure, c'est que je ne suis pas le seul en C++... Pour un Pascalien, c'est euh... sans commentaire !

A plus. Bonne journée. Gilles

PS : L'affaire a de l'importance pour moi. Je ne vais pas travailler avec les TGrids ou les TStringGrids "natives" de FMX mais avec les composant de TMS. Donc si c'est un problème de LiveBindings côté Embarcadero, il le subira aussi. La donne a changé pour moi parce que mon établissement a renouvelé son parc info de PC Windows (avec des Win 7) et remplacé toutes les stations Linux par des Macs et des tablettes... Donc Delphi ou C++ Builder (j'avoue m'être attaché au C++) me conviendrait, sachant que la dernière hypothèque semble levée grâce à FastReport : toutes les archives de l'établissement sont en PDF. Si c'est un bug, il faut le faire remonter mais du haut de mes quelques journées de pratique je ne vais pas m'y hasarder...

[SergioMaster]

je viens d'essayer avec la TMS , idem blocage au 200

Dans le chapeau de dmitry : plein de choses puisque c'est lui le responsable Firedac sur EDN

[Invité]

Donc cela exclut la responsabilité des TMSGrid ou TGrid dans l'action du LiveBindings...
Y a pas le feu... Quelqu'un a des contacts pour signaler ce problème aux "autorités" [Serge->Dmitry... comme cela au hasard...] ?... Y a-t-il un forum de déclaration de bugs ? [J'ai créé un compte DN hier, le compte que je possédais ne semblait plus suffire...]

@Serge : un avis sur les TMS [Eventuellement en MP] ? Sur le papier de tels composants laissent rêveur un Lazarusien.

Cordialement. Gilles

PS : ...Et pour un Lazarusien les bugs sont usuels et admis Je vais aller voir en C++ Builder comment cela se passe...

[free07]

Zut : comment on ajoute des columns à la Tstringgrid en FMX?

En conception c'est bouton droit sur la TStringGrid et choisir 'Ajouter un élément TStringColumn'.

Sinon à l’exécution il suffit d'affecter la valeur voulue à la propriété ColCount.

En ce qui concerne le reste, je peux rien dire vu que je n'utilise pas FireDac mais j'utilise aussi SQLite avec dbExpress et il m'a semblé relativement lent pour charger certaines tables, j'ai pas regardé plus en détails, laissant cela pour plus tard.
Je m'étais dit que c'était peut être du au chargement de certains Blobs qui contient des images d'une taille non négligeable.

D'ailleurs quels sont les avantages liés à FireDac ( par rapport à DBExpress ) ?

Et j'ai utilisé pendant des années Builder C++, maintenant je suis passé à Delphi car les nouveautés sortent d'abords avec Delphi, Embarcadero développe en priorité pour Delphi ensuite, ils passent les nouveautés sur C++.
Il fut un temps ou cela ne me gênait pas, mais ce n'est plus le cas maintenant, d’où mon passage à Delphi.

[Invité]

En conception c'est bouton droit sur la TStringGrid et choisir 'Ajouter un élément TStringColumn'.
Sinon à l’exécution il suffit d'affecter la valeur voulue à la propriété ColCount.

Merci.

D'ailleurs quels sont les avantages liés à FireDac ( par rapport à DBExpress ) ?

Aucune idée. J'ai privilégié ZeosDBO à DBExpress. Le premier m'a semblé d'accès plus simple et surtout, il est portable Delphi Win/Lazarus. FireDac... J'avais testé anyDac aussi... mais choisi Zeos. FireDac n'est-il pas la nouvelle techno promue ? Si DBExpress suffisait pourquoi avoir proposé FireDac ? DBExpress n'est-il pas en train d'occuper la place où il a mis BDE ?

Et j'ai utilisé pendant des années Builder C++, maintenant je suis passé à Delphi car les nouveautés sortent d'abords avec Delphi, Embarcadero développe en priorité pour Delphi ensuite, ils passent les nouveautés sur C++.
Il fut un temps ou cela ne me gênait pas, mais ce n'est plus le cas maintenant, d’où mon passage à Delphi.

Bon à savoir.

Quant aux TMS , mon avis [...]

Merci.... et donc je vous laisse déclarer le problème. Mon anglais est toujours aussi "broken".

Cordialement. Gilles