Discussion :

[SergioMaster]

Bonjour,

cela dépend beaucoup de certaines options du composant FDQuery
En particulier FetchOptions.RecordcountMode, FetchOptions.Mode et autres FetchOptions
comme l'a souligné Buzz c'est plutôt RecordCount qu'il faut utiliser et ce RecordCount va dépendre de ces options (en général pour des requêtes revoyant beaucoup de données on passe par de petits paquets et donc tout n'est pas rapatrié en même temps, juste quand il faut donc RecordCount peut être faux) il vaut mieux utiliser une requête SELECT COUNT(1) C FROM Tb_Barres where signal <> 0' dans ce genre de cas plutôt que de faire un FetchAll qui va ralentir le programme

pour obtenir les 50 premiers résultats et seulement ceux-là c'est une tout autre technique, l'utilisation de la clause après la clause where LIMIT 50

[NewUserDelphi]

En effet la propriété FetchOptions.RecordcountMode était à 50.

Mais je crois en fat que mon pb est celui du débutant qui croit avoir compris...

Je testais le nombre de résultat pour boucler dessus mais je me suis aperçu, c est peut être pas très académique, que au lieu de procéder ainsi il me suffisait de tester en faisant un if EOF et seulement si ce n était pas le cas, alors je bouclais sur les résultats...

Merci à tous pour votre aide et votre patience

[sgmsg]

1.8 M de donnée c'est pas grand chose. J'éviterais les bases de donnée. C'est pas particulièrement rapide

Trier les données ne sert à rien car tu fais probablement des calculs glissants...

Créer un tableau d'entier (jusqu'à l'octet si tu veux en plus sauver de l'espace) de préférence qui optimise la vitesse (suggestion de Paul Toth)

Un octet donne une résolution de 1/2^8 soit 1/258 ou encore 0.004 soit 0.4% ce qui devrait être amplement pour des calculs statistiques
Si l'espace n'est pas un problème un entier non signé c'est 1/2^32 ...

Comme SergioMaster le suggère (?) tu peux convertir les données enregistrés sur disque pour qu'elle soit plus compacte: plus rapide à lire.

De plus tu peux enregistrer le tableau sur disque une fois rempli, ce qui sera encore plus rapide pour le chargement des données.

Le reste c'est de revoir les algos encore et encore afin de trouver de meilleur pratique.

Suggestion: fais des calculs glissants: Lors d'une recherche sur une fenêtre de 10 jours: au lieu de calculer les dix jours précédent pour chaque points, tu enlèves le dernier jour du calcul précédent et ajoute le premier jour pour le jour suivant. ce qui fait une économie de 10 opérations.
Ou fait autrement tu peux calculer la fenêtre de 3 jours suivi de 4, puis 5, etc. ce qui devient alors une addition simple : ultrarapide.

Tu mets dans le tableau des calculs préliminaires mais répétitifs. Si pour chaque jours t'as besoin de l'écart Min-Max, tu rempli un tableau de valeurs min-max ce qui évite, lors de tes balayages, de répéter ces calculs inutiles.

Grosso modo ta ligne de code doit ce résumer à la plus simple expression du genre

t:=a-b+c; //
si t>max alors...
si t<min alors...