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é]

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...

[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

[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.

[SergioMaster]

Gilles , je me ferais un plaisir, au besoin , d'utiliser la langue de chat qui respire pour poser la question sur EDN
Le problème semble plus LiveBindings , mais bon
pour ce qui est des DBExpress le comportement n'est pas totalement identique mais tout aussi 'merdique' (on passe la barre des 200 si l'on essaie de remonter en haut de la grille etc...) .

Quant aux TMS , mon avis ne sera que fractionné (pas assez d'essai en 'exploitation') mais peut être public . (pour les lecteurs je parle de la FMXGrid pas des composants VCL)
J'adorais la Smdbgrid sous VCL , correspondant plus a mes habitudes de présentation (et donc l'habitude de mes utilisateurs) , il a donc fallu s'habituer . Les premières versions étaient plutôt buguées mais la rapidité des corrections a été satisfaisante pour les tests que j'ai pu faire (joint en image la multiselection avec case à cocher)
me reste a savoir gérer les hauts et bas de grille , avant tout autre chose

[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

[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.

[SergioMaster]

Enfin , eureka pour ce qui est de la limite aux 200 , il y avait une "simple" propriété a mettre voir ici https://forums.embarcadero.com/messa...ssageID=614806

mais alors , gilles tu ne vas pas être content du tout, bonjour la lenteur et la conso mémoire , (c'est pour cela que je n'ai pas pu faire le lien direct)

sur ce : bon app

[Invité]

Merci beaucoup Serge pour votre solution et à tous pour le temps consacré à mon problème.

Cela fonctionne. La fluidité est acceptable... Sur 10 000 lignes ! Si je lance l'exe, la consommation mémoire est... acceptable aussi. C'est la consommation de ressource UC qui augmente fortement avec l'action du ScrollBar...

Donc merci. Je vais essayer de trouver de la Doc pour l'incorporation d'images dans les Blob... enfin la gestion des streams ou une manière de l'éviter [pour l'instant je ne vois pas comment...].

Par contre, si la doc Lazarus est une vraie plaie, là, l'approche ressemble à une "pêche miraculeuse"...

Bon app. à vous aussi.
Cordialement. Gilles

[skywaukers]

Bonjour,

curieusement chez moi ça ne fonctionne pas D'abord l'option est décochée par défaut. Et si je place un buffercount ça me charge bien de la quantité de lignes, mais ensuite la pagination est = 1/2 de buffercount, puis plus de pagination.... J'ai Delphi XE5 enterprise update 2

@++
Dany

[Invité]

Bonjour,

curieusement chez moi ça ne fonctionne pas : D'abord l'option est décochée par défaut.

Bonjour,

chez moi elle est aussi décochée par défaut. Je vous transmets mon "projet stable" pour l'instant. La comparaison des paramètres vous donnera peut-être une solution.

Je me permets d'enlever le "Résolu"... pour continuer l'approche. Je ne vais pas ré-ouvrir une nouvelle discussion alors que le problème est toujours l'initiation au LiveBindings... sinon je risque d'en ouvrir beaucoup !

J'ai placé des TEdit de recherche au-dessus de chaque colonne.

Je ne sais pas s'il est possible d'associer par LiveBindings les TEdits de telle manière qu'ils se positionnent dans la colonne avec la valeur recherchée. Pour l'instant j'utilise ce code :

Code :

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

1
2
3
4
5
6
procedure TForm1.NomSEARCHChangeTracking(Sender: TObject);
begin
  if FDQuery2.IndexFieldNames <>  'tenom' then  FDQuery2.IndexFieldNames := 'tenom';
  if  length(tedit(sender).text) =0 then FDQuery2.FindFirst else
    FDQuery2.Locate('tenom', tedit(sender).text, [loCaseInsensitive, loPartialKey]);
end;

C'est fonctionnel

La question de l'association par LiveBindings s'est posée -et se pose toujours- quand j'ai voulu associer la variation d'une largeur d'une colonne à la souris et celle (automatique donc) de la largeur du TEdit de recherche placé au-dessus... Et là

J'ai refait plusieurs ma TGrid à 3 TColumns -histoire d'automatiser l'approche-... et l'Inspecteur d'Objet est fort différent après l'approche LiveBindings:

J'ai lié chacun des champs du DataSet de la Grid avec les colonnes de celles-ci. A priori c'est OK.

En Lazarus, j'utilise l'évènement onResize de la colonne mais depuis que j'ai "LiveBindé" les colonnes de la Grid, elles n'ont plus d'évènements ?????
Peut-être dans ceux de LinkGridToDataSourceBindSourceDB1.GridControl [c'est le nom auto-affecté]... Il y a bien un évènement OnResize mais c'est pour la TGrid.

Merci d'avance.
Cordialement. Gilles

Ajout 15:40
Pour ajuster mes TEdits de recherche, j'ai utilisé l'évènement OnPaint de la Tgrid. Mais est-ce la bonne approche ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
procedure TForm1.Grid2Paint(Sender: TObject; Canvas: TCanvas;
  const ARect: TRectF);
begin
  if not((idSEARCH.Width  = grid2.Columns[0].Width)
     and (nomSEARCH.Width = grid2.Columns[1].Width)) then begin
    idSEARCH.Position.X :=  grid2.Position.X + Grid2.Columns[0].Position.X;
    idSEARCH.Width := grid2.Columns[0].Width;
    nomSEARCH.Position.X :=  grid2.Position.X + grid2.Columns[1].Position.X;
    nomSEARCH.Width := grid2.Columns[1].Width;
    Invalidate; //Pourquoi obligatoire?
  end;
end;

L'ensemble reste fluide.

Comme sous Lazarus, j'ai réduit la taille de l'exécutable en allant décocher Projet->Option->Compilateur Delphi->Liaison ->Information de débogage (donc maintenant false pour le produit final). Dans mon cas l'exe passe de 34Mo à 9Mo. Mais pour le reste, où est la doc "fine" (ie exhaustive) ?

[skywaukers]

Bonjour,

chez moi elle est aussi décochée par défaut. Je vous transmets mon "projet stable" pour l'instant. La comparaison des paramètres vous donnera peut-être une solution.

Merci pour la source. Par contre je vois : buffercount = 2000000. Il n'y a donc pas de pagination, tout est chargé d'un bloc donc heureusement oui ça fonctionne. Par contre ça va parce que les données sont en mémoire, elle proviendraient d'un serveur distant le temps de réponse ne serait surement pas bon, d'où l'intérêt d'une pagination. Pagination qui semble malheureusement mal fonctionner... Ou il manque des infos.... Cela ressemble quand même à du travail trop vite fait tout ça (mais avaient-il la possibilité de prendre leur temps...) Espérons que maintenant que la majorité des plates-formes populaires sont couvertes, ils vont mettre le paquet pour stabiliser et documenter tout ça.

@++
Dany

[Invité]

Bonjour Dany,

Tout à fait pour la pagination... j'utilisais la base SQLite en :memory:. Pour une base stockée sur un disque dur, en Lazarus je pratique ainsi:
Chargement des 100 premiers enregistrements... quasiment instantané... Les champs de recherche s'ils existent sont inactifs... L'utilisateur peut modifier, insérer, supprimer, dupliquer les enregistrements affichés. Je pars du principe que ces opérations doivent être immédiatement à disposition sur les enregistrements les plus "récents" par exemple dans le cas d'un forum...

Parallèlement dans un Thread le reste du chargement est lancé [101 à 10000]. Quand il est terminé les champs de recherche deviennent actifs. Mais pour faire ceci, j'ai dû passer par des TStringGrids... Je suis capable de Threader la chaine de connexion jusqu'au Dataset inclus mais pas le Datasource.... donc pas de dbGrid.... J'ai testé cela sur Win32, 64, Linux 32 et 64 et OSX32.

Donc pour revenir à Delphi et obtenir la même fluidité, je pensais pratiquer comme en WinDev... Comme je n'imagine pas répliquer mon approche avec le LiveBindings], je comptais utiliser une base tampon SQLite :memory:. Au début du programme, pendant la période d'identification de l'utilisateur, on charge intégralement la base en mémoire. En WinDev cela me prend 1min30. C'est acceptable parce qu'après, le programme est fluide. Cela présente un autre avantage. Les bases pgSQL et mySQL sont distantes (hébergées)... En cas de rupture de connexion, il y a peu d'incidence sur le programme. Les mises à jour peuvent même être réalisée en différé.

D'autant que je me rends compte que Delphi est devenu "poussif" en usage par défaut dans certaines de ses pratiques. L'utilisation des Streams sur l'exemple que j'ai donné est flagrante. Remplissage de 10000 memoryStream à partir d'une vignette png 16*16 stockée dans un Timage ou équivalent :

• WinDev18 -> 2 secondes
• Lazarus 1.1 ->0.7"
• Delphi 7, je l'ai ressorti spécialement :même ordre de grandeur que Lazarus : Et oui pas mal l'ancêtre. Quel fabuleux produit !
• Delphi XE5 FireMonkey : entre 15 et 17"*, oui dix sept, je n'ai pas oublié la virgule
• Delphi XE5 VCL : idem entre 15 et 17 "

Les tests et sources sont à dispositions....

Je suis sûr que l'on peut optimiser Delphi XE5 mais la question est de maîtriser les nombreuses options... Des "trucparanoïd" comme intitulé de paramètre... Cela ne m'évoque rien ! Si, cela me donne l'envie de fuir ! Et s'il n'y avait que cela... leur nombre est... considérable et avec le LiveBindings, le niveau d'imbrication devient redoutable : il faut trouver les points d'affection au bon endroit... Bref, il faut être un expert et pour le devenir je dois posséder une Doc "orientée" à cette intention. Finalement, je me moque bien de savoir comment M. X fait son programme pour répondre à ses exigences et à elle seules. J'ai besoin de répondre aux miennes ! J'ai une formation scientifique dont je suis très fier et me sens d'ailleurs très redevable et que j'essaie de transmettre... et pas celle d'un sorcier dont je refuserais d'ailleurs toutes les approches !

Cordialement.
Gilles

*En exe cela dépend des options du compilateur. Pour Lazarus et Delphi 7, ce sont les configurations par défaut.