Discussion :

[Legendary434]

Bonsoir chers tous, je me demande sur la faisabilité de tâche parallèle dans mon cas
Pour la petite histoire je suis jamais arrivé a comprendre le principe des tâche parallèle.

J'ai un fichier excel de plus 400 000 ligne provenant d'une autre base de données.
J'aimerais importé ce fichier dans ma base HFsql pour celà j'utilise une table pour afficher les données du fichier excel avant le transfert dans ma base. Mais le seul chargement du fichier Excel dans la table fait plus de 40 min. Pour le transfert dans la base c'est catastrophique.
Ma question est-ce possible ou envisageable de parallelisé un tel chargement pour gagner plus en performance.

Très cordialement

[tbc92]

Le dialogue Windev/Excel est très lent. Ce n'est pas spécifiquement Windev qui est en cause, on adresse Excel Cellule par Cellule, c'est très lent.

Une première étape est de sauvegarder le fichier Excel en CSV , puis de traiter ce fichier CSV.

Tu peux faire la sauvegarde via Excel dans un premier temps , juste pour comparer la fin du traitement (lecture du fichier CSV , import dans ta base de données).
Tu peux aussi piloter cette sauvegarde à partir de Windev.
Tu vas diviser tes temps de traitements par 10 voire plus.

Après, pour l'import d'un fichier CSV dans la base de données, si tu es certain que ton fichier est totalement propre, tu peux faire une série de hEcrit au lieu de hAjoute. Regarde les docs de ces 2 fonctions pour comprendre les différences.

Dans les 2 cas, un hReindexe() à la fin de l'import est soit conseillé (si tu fais des hAjoute), soit indispensable (si tu fais des hEcrit)

[Legendary434]

Merci beaucoup tbc92 pour votre promptitude je vais essayer ça aussi voir, mais est-ce qu'il y a une possibilité de paralléliser ?

[tbc92]

Si tu veux de la performance, il y a d'autres pistes.
- Supprimer tout ce qui est Excel
- Remplacer HFSQL par des outils plus performants. Je travaille beaucoup avec Oracle. Sur Oracle, si on charge un fichier ligne à ligne, ou si on remplace ce chargement ligne à ligne par un chargement de type 'SQLLoader', on divise les temps par 50 environ. Entre autres parce que le chargement ligne à ligne demande autant d'appels au serveur qu'il y a de lignes. Alors que le chargement par SQLLoader dit au Serveur : coucou, peux tu insérer ces 100 lignes, et rappelle moi quand ce sera fait.

En local (la base sur le même PC que le fichier TXT), l'écart sera moindre, mais pour avoir des vraies bonnes performances, en général, on ne travaille pas sur un PC, mais un serveur de données.

J'imagine que tu travailles en HFSQLClassic, et pas en HFSQL CS.
Sur HFSQL CS il y peut-être des utilitaires qui permettent d'accélérer les imports. C'est une piste à explorer si tu as besoin de performances, et que tu tiens absolument à rester en HFSQL.
En gros, HFSQLClassic, c'est le jouet pour s'entrainer, HFSQL CS, c'est la version sérieuse de HFSQL. Et MySQL ou PostGre ou Oracle, ce sont des vrais SGBDR, sans commune mesure avec HFSQL.

Sinon en restant avec les outils de base (HFSQLClassic), il y a un autre truc qui peut accélérer, c'est d'utiliser les transactions. A vérifier quand même si c'est compatible avec hEcrit.
Pour hEcrit, je suis sûr que ça améliore énormément les performances, les transactions, je suis moins sûr.

[Legendary434]

À vrai dire j'ai donné le choix à l'utilisateur final soit en HFsql classique ou C/S
Je n'ai jamais essayé de développer avec d'autres SGBDr, j'étais tenté par MySQL mais je m'inquiétais pour certaines requêtes. Je ne suis pas trop expert en WinDev j'ai eu à développer plusieurs applications même en mobile.

Sinon mon vrai soucis c'est avec les tâches parallèles je suis jamais arrivé à l'implémenter. Je vais me lancer dans MySQL aussi je me disais que ça doit être limité avec WinDev.

[tbc92]

Les taches parallèles, l'idée est de tirer parti des nombreux processeurs. C'est utile pour des taches qui vont utiliser/saturer les processeurs.
Ici, tu as des taches qui utilisent le disque dur, et qui ne font que ça à peu près. Un seul disque dur, et plein de taches qui vont lui donner des ordres plus ou moins contradictoires : La tache 1 demande de lire la ligne 100, pendant que la tache 2 demande de lire la ligne 3000.
Le disque dur va devenir fou à force de recevoir des instructions contradictoires. Il va passer son temps à courir d'un bout à l'autre de l'entrepôt, pour satisfaire tout le monde en même temps.
Le traitement n'ira pas plus vite, parce qu'il y a un seul disque dur de toutes façons, il ira peut-être même moins vite. Avec le risque de plantages.

[Legendary434]

Les taches parallèles, l'idée est de tirer parti des nombreux processeurs. C'est utile pour des taches qui vont utiliser/saturer les processeurs.
Ici, tu as des taches qui utilisent le disque dur, et qui ne font que ça à peu près. Un seul disque dur, et plein de taches qui vont lui donner des ordres plus ou moins contradictoires : La tache 1 demande de lire la ligne 100, pendant que la tache 2 demande de lire la ligne 3000.
Le disque dur va devenir fou à force de recevoir des instructions contradictoires. Il va passer son temps à courir d'un bout à l'autre de l'entrepôt, pour satisfaire tout le monde en même temps.
Le traitement n'ira pas plus vite, parce qu'il y a un seul disque dur de toutes façons, il ira peut-être même moins vite. Avec le risque de plantages.

Merci beaucoup tbc92, j'ai changé de PC core i7, le chargement est beaucoup plus rapide et limpide. Un grand merci a tous je marquerai comme résolu.

[frenchsting]

Merci beaucoup tbc92, j'ai changé de PC core i7, le chargement est beaucoup plus rapide et limpide. Un grand merci a tous je marquerai comme résolu.

Bonjour,

J'ajoute un conseil à ceux déjà prodigués ici :
- Attention à la différence qu'il y a entre ta plateforme de développement et les ordinateurs cibles. Sur un Pc i7 avec ssd ça ira bcp plus vite que sur le pc d'un client qui à un dual core à bout de souffle. Et c'est le client qui a raison