Il était une fois... Oui, un peu de détente ne fera de mal à personne.

... un développeur face à un petit projet 'facile'. Il le développa avec ardeur dans sa technique habituelle et obtint des résultats convenables avec une petite base de test que lui fourni son client qui était lui aussi développeur.

Soudain, survint le client final, avec son air grognon et encore du sang de développeur qui tâchait ses sabots. Le client final avait dévoré des générations de développeurs et comptait bien continuer ainsi. Il leur soumis donc une copie de sa base pour que nos gentils développeurs testent le projet.
- "ET si cela ne marche pas en moins de 10 seconde..." hurla-t il de sa voix tonitruante en claquant la porte du garage de nos gentils développeurs (les développeurs travaillent dans leur garage selon la légende, c'est moins distrayant que le salon, ou la xxxBox est branchée sur la télé pour les bébé développeurs).

Le soir venu, notre développeur commença ses test. 3 Minutes ! il fondit en larme en pensant "comment faire ???"

Son projet parcours des fichiers HyperFile pour extraire des données dans des fichiers textes. Rien de compliqué.

Il se remémora les présentations WinDev et se rappela l'analyseur de performance. Il se précipitat pour le lancer et s'aperçu quels furent les ordres de son programme qui consommaient du temps. Il en déduit aussi qu'en les dépaçant dans sont algorythme, il obtiendrait le même résultat tout en les exécutant moins souvent. L'espoir revint...

Après quelques heures de travaux sur son algorithme, il se trouva face à une limite supposée infranchissable : le parcours de ses fichier. Dans sa programmation académique, notre développeur utilisant le parcours classique : hLitPremier, TANTQUE et hLitSuivant.

Il eu alors l'idée de contacter des proches qui avaient survécus au client final lors de la livraison de leurs projets. Peut être avaient-ils une recette miracle...
Effectivement, elle a même un nom : les vues.
Plutôt que de démultiplier les accès disques à chaque ordre hLit, l'utilisation des vues permet de charger massivement en mémoire les données à lire. Le parcours (et la recherche) est alors effectuée uniquement en mémoire et devient trés rapide.
Fort de ce nouvel enseignement, notre développeur les implémenta avec succès (et pas mal de tests) au point de remplacer l'utilisation de filtres sur des fichiers liés dans ses boucles par des parcours bornés de vues.

Il pratiqua aussi la même idée (limiter les accès disques au profit de la mémoire) en utilisant des variables pour stocker le contenu de ses fichiers à la place des fEcritLigne.

Le résultat était presque là. Mais il était encore à 30 secondes pour produire ses 3 fichiers.

Alors il fit appel à un trés vieux développeurs, surnommé 'Docteur' en raison de la science qu'il avait cumulé pendant ses nombreuses années à cotoyer les dangereux client finaux.
Contre un bol de soupe au pistou (il s'en fout de son haleine, à son age, le docteur... ) lentement absorbé et après avoir tiré sur sa pipe, le vieillard indiqua à notre développeur comment mettre en place l'export de ses 3 fichiers dans 3 threads qui seraient exécuté en simultanés.
Aprés quoi, dans une boucle, il suffit d'attendre que chaque thread ai fini son exécution. Le traitement fut ramené à la durée de l'export le plus long !

Notre développeur pu constater un résultat impressionant lors de la démonstration final au client final : 9 secondes.
Le pari fut donc tenu et il pu songer aux mots de ses contacts lors de cette aventure : Si ton programme ne te satisfait pas, pense aussi que ce peut être à cause du développeur.

L'histoire ne peut préciser ce que devint le client final, faute de nouvelles...

MDR

a+

Totof

Dans le même genre, on a un serveur qui ponds chaque jour un fichier de log (en .txt) de 100 Mo (+ ou -), et évidemment, il fallait chercher une communication dedans... et vite en plus...

Dans premier réflexe (car la recherche peut être faite temps réel pour le service client, donc pas le temps d'intégrer en HF, vu le temps que ça prends):
-> flitligne() avec peut être un fichier d'index pour ranger un peu les communications et tricher sur l'offset de départ... Super lent, genre 3 minutes... ok, on laisse tomber...
-> bon, ok, alors flit() par tranche de 1 Mo (mais faut gérer les lignes à la main et les données qui restent entre les lignes, mais bon), 1 minute,
-> bon ok, tu m'enquiquines toi là bas dans le fond, mange toi 4 threads sur le principe de la dichotomie (ouais bon, quadrichotomie) sauvage avec des flit à 2 Mo... 2 seconde... Ah ouais... Y'a miam dichotomie Encore un peu je ressortais le QuickSort des familles pour l'adapter...

Résultat, entre moins d'1 et 6 secondes (si le serveur est chargé) pour trouver le record (et les events suivants) dans un fichier de 100 M...
Corrolaire, jeter à la poubelle flitligne qui est décidément beaucoup trop lent...


Dans une prochaine aventure, je vous parlerai du dév qui prétendait que Windev était tellement lent que même une appli en PHP tournait plus vite...
C'est sûr que vu comment il codait en Windev...

Voilà le genre d'aventures qui doivent tous nous apprendre à rester modestes.
Ce n'est pas parce que nous n'avons pas la solution qu'elle n'existe pas.
Merci encore à toute la communauté pour les multiples réponses apportées aux problèmes sans solutions.

"L'union fait la force"
[modérateur]Non ! elle fait la Forge[/modérateur]