Discussion :

[djibxav]

Bonjour,

Je suis en train de mener des tests afin de décider sur quels support de données s'appuiera la refonte d'un logiciel.

HF classic à le côté pratique d'être plutôt bien embarqué et livrable avec Windev sans install externe, seulement je le toruve régulièrement lent, j'ai donc mené le test suivant.

Je crée un projet avec une analyse en HF classic.
J'installe un SQL Express et un MySQL sur ma machine

Tous comportent la même table avec exactement les mêmes index.
La table comporte 5 champ: ID automatique, Nom, Prenom, N°Sécu, un champ numérique simulant une clef externe.
Je remplis avec 1000 lignes, puis je lis 1000 fois 2 requêtes distinctes:
-l'une qui extrait les hommes via le N°Sécu afin de faire un where sur une partie d'un champs texte
-l'une qui cherche les gens portant un indice donné du champ simulant la clef externe

Je lance ce test sur HF classic un fois en requetant en SQL une fois avec les requetes construites via Windev
Je lance aussi sur SQL Express en ODBC, MySQL en ODBC, et MySQL en classic

Je chronomètre le tout et voilà ce qu'il en ressort:

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
 
Création d'un jeu de test de 1000 Personnes
 
Evaluation HF Classic  via requetes SQL
Insertion de 1000 Personnes
0.66s
Selection des hommes
1.57s
Selection filtrée sur champ numérique indexé
1.57s
 
Evaluation HF Classic via requetes WD
Insertion de 1000 Personnes
1.09s
Selection des hommes
2.14s
Selection  filtrée sur champ numérique indexé
1.57s
 
Evaluation MySQL Natif
Insertion de 1000 Personnes
0.11s
Selection des hommes
0.34s
Selection  filtrée sur champ numérique indexé
0.13s
 
Evaluation MySQL ODBC
Insertion de 1000 Personnes
0.13s
Selection des hommes
0.57s
Selection  filtrée sur champ numérique indexé
0.2s
 
Evaluation SQLExpress ODBC
Insertion de 1000 Personnes
0.51s
Selection des hommes
0.43s
Selection  filtrée sur champ numérique indexé
0.12s

Sur un autre test qui consiste à faire une requête sum() sur +/- 130000 enregistrement parmi 1.8 millions, filtrés sur un champ indexé, SQL Express est de l'ordre de 40 fois plus rapide que HF classic (en l'occurrence 0.25s contre 8 secondes).

Dois-je être surpris où est-il juste normal qu'HF soit autant à la ramasse ?
Y'a-t-il un truc que j'aurais raté qui pourrait faire que HF classic reste une option viable et non un frein ?

[courdi95]

Merci pour cette comparaison, que je n'avais jamais tentée mais qui a le mérite d'être objective.

Je suis surpris des mauvais résultats de hfsql. Si quelqu'un a une idée de ce qui se passe, je suis également preneur.

[ben-34]

Effectivement, il y a des différences de performances indéniables. Les produits comparés n’ont pas tous la même maturité : HF reste une solution propriétaire (avec peu de contributeurs) qui est relativement jeune.

HF peut être un très bon allié, mais un ennemi dans certains cas.

Son énorme avantage, est la portabilité des données et la facilité de gestion. De plus, sa gestion est parfaitement intégré à WinDev.
Le principal inconvénient, est l’opacité de l’éditeur : Il y a des comportements navrant, et personne ne peut apporter une solution, ni même une méthode pour contourner ces problèmes (mais je ne souhaite pas polémiquer là-dessus).

Ma conclusion :
Il faut bien choisir son SGBD, en fonction du type de projet, des performances désirées et des besoins d’administration.

[frenchsting]

C'est un sujet déjà abordé dans ce forum...

HF a l'inconvénient de ses avantages : ultraportable mais relativement lent. Si c'est transparent sur une petite base, cela devient pénalisant sur une base conséquente.

[vouilloz_d]

Salut djibxav,

Tu as la possibilité de tester avec HFCS à titre de comparaison ?
Juste par curiosité

[courdi95]

Bonjour

Peux-tu nous envoyer ton projet de test ? Afin que je puisse le faire tourner sur mon PC et le comparer avec tes chiffres ?

Je suis vraiment déçu ... quand on voit les démonstrations qu'ils font lors du TDF (avec une base de données de milliards de données), je me pose des questions.

[frenchsting]

Bonjour

Peux-tu nous envoyer ton projet de test ? Afin que je puisse le faire tourner sur mon PC et le comparer avec tes chiffres ?

Je suis vraiment déçu ... quand on voit les démonstrations qu'ils font lors du TDF (avec une base de données de milliards de données), je me pose des questions.

- Un disque SSD
- Un max de RAM
- 3 rubriques dans le fichier
- Lancé une première fois pour avoir le maximum de données en cache.

[hpascal]

Bonjour

Il n'y a que Pcsoft qui ne sait pas que HF a un problème de performances

Ce qui ne m'empêche pas de l'utiliser. Comme le disent @ben-34 et @frenchsting, ça dépend du besoin
Le gros avantage pour les débutants c'est l'intégration totale dans l'environnement de Windev
Mais utiliser d'autres bases de données est à peine plus compliqué et on en mesure vite les avantages

Ta démarche est très bien : si les performances sont importantes il faut faire des benchs pour choisir en conséquence.
ça prend un peu de temps mais ça permet de faire le bon choix

Il faudrait tester aussi en réseau et avec des requêtes contenant quelques jointures.
Il faut aussi exécuter plusieurs fois la même requête et faire une moyenne, en général les exécution suivantes sont plus rapide avec la mise en cache
Et si possible avec un volume de données plus important pour que ça soit significatif

Dans tes choix tu pourrais ajouter aussi PostgreSql, accès natif gratuit, diffusable librement, performant

Bons dev

[djibxav]

Salut djibxav,

Tu as la possibilité de tester avec HFCS à titre de comparaison ?
Juste par curiosité

Je ne l'ai pas mis dans ce test, mais je l'avais testé et ça donnait les mêmes chiffres qu'en Classic.

Il faudrait tester aussi en réseau et avec des requêtes contenant quelques jointures.

C'est pour une appli monoposte avec la DB embarquée (ou au pire des cas installée sur le même poste sin on embarcable), donc je n'ai pas poussé les benchs réseau.

Il faut aussi exécuter plusieurs fois la même requête et faire une moyenne, en général les exécution suivantes sont plus rapide avec la mise en cache

Dans mes benchs les temps sont des sommes de temps d'exécution de 1000 requêtes.

Et si possible avec un volume de données plus important pour que ça soit significatif

J'ai pas mis le détail du bench, mais j'en parlais en fin de message, j'ai testé sur une table 1.8M enregistrements. HF était à la rue, et niveau cache, probablement absent car SQL Express gagnait quelques centièmes à la 2eme execution, HF reprenant exactement le même temps.

Dans tes choix tu pourrais ajouter aussi PostgreSql, accès natif gratuit, diffusable librement, performant

Je vais l'ajouter à mon scope, j'ai aussi Interbase dans le radar.

[courdi95]

Bonjour

Est ce que tu peux partager ton projet windev pour tester sur mon pc ?

[djibxav]

Bonjour

Est ce que tu peux partager ton projet windev pour tester sur mon pc ?

Malheureusement, c'est pas trop possible, ce test est noyé dans un projets rempli de tests et benchmarks avec plein de code de la boite ou je bosse dedans.

Mais c'est pas très long à refaire, une analyse, recopiée à l'identique dans différents sgbd, une classe par sgbd et c'est parti.

[courdi95]

Franchement, c'est dommage ....

Sans vouloir remettre en cause l'honnêteté et l'intégrité de ton analyse, il serait quand même judicieux que tu publies officiellement le projet qui a servi de base à tes essais.

Je pense que tu comprendras qu'une publication dans ce forum public de résultats doit être validable sur des données et des ressources partageables.

Comme tu m'as indiqué le projet de test est simple à faire, donc il est peut être simple d'extraire ce projet des autres benchs dont tu parles ?

[JG_33]

Avec quelle version de windev as tu fais tes tests ?

Pour avoir fait beaucoup de tests je confirme que Windev est plus lent mais à ce point sur un simple select ça m'étonne

Je viens de faire un test en C/S avec wdsql 20 sur un fichier client de 56277 enregistrement
Recherche des adresses qui commencent par "le". Adresse n'est pas une clé comme le no de sécu dans ton test
SELECT * FROM client1 WHERE adresse LIKE 'le%'

le résultat affiche les 1847 lignes en 0.62s
Ce n'est pas foudroyant mais pour le commun des mortels, 0.62s ou 0.2 ne changera pas beaucoup sa vie

Au TDF ils ont bien soin de nous épater avec une base qui contient des milliards d’enregistrements, mais ce qui fait vraiment souffrir les moteurs sql ce sont plutôt les jointures multiples et un bon group by par dessus !

[courdi95]

Avec quelle version de windev as tu fais tes tests ?

Pour avoir fait beaucoup de tests je confirme que Windev est plus lent mais à ce point sur un simple select ça m'étonne

Je viens de faire un test en C/S avec wdsql 20 sur un fichier client de 56277 enregistrement
Recherche des adresses qui commencent par "le". Adresse n'est pas une clé comme le no de sécu dans ton test
SELECT * FROM client1 WHERE adresse LIKE 'le%'

le résultat affiche les 1847 lignes en 0.62s
Ce n'est pas foudroyant mais pour le commun des mortels, 0.62s ou 0.2 ne changera pas beaucoup sa vie

Au TDF ils ont bien soin de nous épater avec une base qui contient des milliards d’enregistrements, mais ce qui fait vraiment souffrir les moteurs sql ce sont plutôt les jointures multiples et un bon group by par dessus !

Cela va dans le sens de mon post concernant la publication des projets ayant servi aux tests : il serait judicieux que les résultats de tests soient publiés avec le projet ayant fait le test.

@JG_33 : peux tu nous fournir ton projet de test ?
@djibxav : je réitère ma demande.

Sans possibilité de tester vos projets, vos résultats ne peuvent être pris en compte qu'avec ce léger doute qui subsiste ...

[djibxav]

Avec quelle version de windev as tu fais tes tests ?

16 à la base et testé en 19 par acquis de conscience sans aucune amélioration

Pour avoir fait beaucoup de tests je confirme que Windev est plus lent mais à ce point sur un simple select ça m'étonne

Je viens de faire un test en C/S avec wdsql 20 sur un fichier client de 56277 enregistrement
Recherche des adresses qui commencent par "le". Adresse n'est pas une clé comme le no de sécu dans ton test
SELECT * FROM client1 WHERE adresse LIKE 'le%'

le résultat affiche les 1847 lignes en 0.62s

Sur une seule requête ?
Dans mon test, c'est 1000 select.
0.62s sur une requête => poubelle

Ce n'est pas foudroyant mais pour le commun des mortels, 0.62s ou 0.2 ne changera pas beaucoup sa vie

0.42s, si c'est sur un seul select, quand tu sais que tu va en faire 100, ça rend juste l'application pas livrable sans une grosse honte.

Dans toute ma carrière, une bonne requête c'est 32ms, 100ms pour les plus gourmandes (exception faite des requêtes capilotractées qui prennent 1 page A4 à imprimer pour lesquels je laisse jusqu'à 0.5s à 1s avant de me fâcher).
Mais je n'ai jamais eu à utiliser HF.

[courdi95]

Est ce que ta base est bien indexée ?

Le mieux pour éviter toute incertitude, ce serait quand même que tu partages ton projet. Au moins, chacun pourrait se faire sa propre opinion sur le MEME projet.

[Invité]

Bonjour,
j'ai démarré un projet similaire que je mettrais à disposition de la communauté quand il sera opérationnel.
J'envisage de faire des tests sur la dernière version 20, sur les bases HF et mySQL, pour des INSERT et des SELECT
Je n'ai pas trouvé sur internet de comparatif suffisamment récent, et comme l'auteur de ce sujet ne peut pas partager les sources va bien falloir qu'on s'y mette pour apporter une réponse à la question : HFSQL est il lent?

Pour le moment j'ai fait un fichier de test, lequel contient:
IDAutomatique
Nom
Prenom
Numero Secu
Cle Secu
Entier aléatoire

J'ai crée une requete par windev, qui fait un INSERT. Les valeurs des champs viennent d'une fonction qui génère des chaines au hasard.

Si vous avez des orientations à me donner, j'écoute.