Bonjour,

Je vois que ce sujet a été traité quelques fois, mais comme les choses
évoluent et que je suis "nouveau" sur WinDev, j'ose imaginer qu'il y a soit
eu des nouveautés depuis ces posts, soit j'ai quelque chose de mal configuré.
J'ai plusieurs années d'expériences avec des DB SQLite, je sais à quel niveau
de performance on peut s'attendre même sur une base de données "locale".

Le projet sur lequel je travaille possède une base de données HFSQL
"classique" (donc locale). En réflexion sur une fonctionnalité, je voulais
voir ce que HFSQL peut encaisser en volume de données avant de valider une
solution technique.

J'ai donc créé une table très simple: un identifiant (entier, clé primaire),
une valeur texte (rempli avec des guid, mais peu importe). Cette table
contient 100 000 lignes. Mon test est simple: lire chacune des lignes avec
autant de requête en utilisant l'identifiant, donc... 100 000 requêtes.

D'autre part, à titre de comparaison, je crée la même table dans une DB
SQLite.

Après quelques constats sur la libération des sources de données, je fais un
benchmark des 3 codes suivants:

1e version, avec libération des sources de données, avec DB HFSQL


2e version, sans libération des sources de données, avec DB HFSQL


3e version, DB SQLite


Voici les résultats obtenus (en secondes), en fonction du nombre
d'enregistrements lus

* Etant donné le temps que cela prendrait, je n'ai même pas fait ce test dans
ce cas.

A noter que, bien évidemment, sans libération des ressources, l'empreinte
mémoire explose littéralement: 2,7Go en RAM pour seulement 100 000 lignes
lues!
A coté de ça, le moteur SQLite ne bronche pas, l'empreinte mémoire est
inexistante.
J'ai fait un test en utilisant les mêmes méthodes que SQLite pour HFSQL, les
résultats sont les mêmes. Le problème viendrait donc bien du moteur de base
de données. Ou, je l'espère, d'un problème de configuration dans ma base de
données.

Je suis perplexe, et mon choix technique dépend, évidemment, fortement des
performances du moteur HFSQL.

Quelqu'un aurait-il une idée ou une indication à tester?

Merci!

@Benjamin
J'ai donc réalisé en plus un test "croisé":
1 - accès SQLite avec les fonctions "H"
2 - accès HFSQL avec SQLConnecte et autres fonctions SQL

Le test 1 donne un résultat 10x plus lent que du SQLite avec accès "SQL" simple, mais ça reste 50x plus rapide que HFSQL avec les fonctions "H" (avec libération des requêtes).

Le test 2 ne change rien, même temps d'exécution que du HFSQL accédé avec les fonctions "H". Mais pour le même timing, la répartition est différente entre l'exécution de la requête et la libération des ressources:
- 5,8% pour HExecuteRequeteSQL() et 92,3% pour HLibereRequete()
- 27% pour SQLExec() et 72,3% pour SQLFerme()

Mais ma question à la base c'est surtout: est-ce qu'il y a des choses particulières à configurer pour que ça tourne mieux que ça?
Je passe régulièrement un coup de WDOptimiseur sur ma DB avec recalcul des index et des stats. Mais ma DB ne change pas, donc aucune raison de voir un changement avec ça.

VincentRG : Depuis le début j'étais persuadé que vous étiez en client /
serveur du coup effectivement oublier le SQL en HFSQL en local les
performances seront toujours catastrophiques par rapport aux fonctions H
Je suis par contre intéressé par l'idée que soulève Benjamin à savoir <
migrer "secrètement" vers du Sqlite > mais attention, je crois pas que toutes
les rubriques (clef composé ... tableau...) soit supportés par Sqlite (après
je connais pas bien SQLite) mais si sa marche je vais aller chercher 2 3
vieux projet et les migrer direct surtout si les fonctions H sont supportés
cela sera que plus rapide.

Ce genre de cas (multitude de requêtes SELECT) est un cas de figure "pratique". Lorsqu'on implémente le design pattern DAO, c'est justement ce qu'il se passe.