Discussion :

[Tenebrous]

Bonjour,

J'ai une question qui me turlupine depuis un petit moment.

J'ai codé un programme sous C++ Builder 5 qui effectue d'assez gros traitements (de l'ordre de 10 minutes en moyenne pour arriver au résultat escompté). Ce programme va rechercher des informations en BDD, effectue des traitements et crée ensuite divers fichiers sur base de ces données.

Le problème est le suivant : quand je lance le programme depuis l'IDE, les traitements s'effectuent BEAUCOUP plus rapidement que lorsque je le lance depuis la ligne de commande (le programme est destiné à recevoir des arguments de la ligne de commande). Je ne comprends pas une telle différence. D'où cela pourrait-il provenir ?

Merci d'avance.

[Ekleog]

Compiles-tu bien en mode release ?

Passes-tu des arguments en ligne de commande que tu ne passes pas par l'IDE ?

Combien est "beaucoup" ? Si ça se compte en une dizaine de secondes, ça peut être le chargement des libs dynamiques ou autres qui sont gardées préchargées lors du lancement dans l'IDE, sinon c'est une différence plus structurelle.

Le ralentissement est-il proportionnel au temps mis par le programme à s'exécuter ?

Si tu compiles en release et en debug, lances-tu bien le programme compilé en mode release ?

[Tenebrous]

Désolé pour la réponse si tardive.

Alors non, je ne compile pas en mode release, je suis en mode debug (j'ai encore régulièrement besoin de débugger). Par contre, je ne comprends pas bien, comment cela pourrait-il provenir de là vu que si je suis en mode debug, je le suis aussi bien dans l'IDE que lorsque j'exécute l'exécutable depuis la ligne de commande (vu que c'est le même), non ?

Les arguments de la ligne de commande sont exactement les mêmes dans un cas comme dans l'autre (C/C).

Quand je dis beaucoup, c'est presque de l'ordre du double.

Quant à la question de la proportionnalité, je n'en suis pas certain mais je dirais que oui (pas certain car j'effectue toujours mes tests sur les mêmes données pour pouvoir comparer efficacement).

[Tenebrous]

Après compilation en mode release et test des deux manières, voici les résultats :

Via IDE :
09:14:14,492 *** Generation V2.0 started on 22/03/2012 9:14:14 ***
09:25:03,772 ------ End of Generation
TOTAL : 10 min 49 sec

Via ligne de commande :
08:22:05,615 *** Generation V2.0 started on 22/03/2012 8:22:05 ***
09:07:39,072 ------ End of Generation
TOTAL : 45 min 34 sec

Bref, encore pire que ce que je pensais à la base...

Je me demandais :
Lorsque je l'exécute sous l'IDE, l'exe est contenu dans le dossier du projet (donc avec tous les autres fichiers .h, .cpp etc.) alors que lorsque je l'exécute via la ligne de commande, je recopie au préalable l'exe dans un autre dossier (et uniquement lui). Ca proviendrait de là d'après vous ? Se pourrait-il que l'absence de certains des fichiers présents dans le dossier du projet soit à l'origine de cette lenteur ?

Merci d'avance.

[Bousk]

Je me demandais :
Lorsque je l'exécute sous l'IDE, l'exe est contenu dans le dossier du projet (donc avec tous les autres fichiers .h, .cpp etc.) alors que lorsque je l'exécute via la ligne de commande, je recopie au préalable l'exe dans un autre dossier (et uniquement lui). Ca proviendrait de là d'après vous ? Se pourrait-il que l'absence de certains des fichiers présents dans le dossier du projet soit à l'origine de cette lenteur ?

Merci d'avance.

Non, le but de la compilation c'est de proposer un executable indépendant; en plus de ne pas fournir les sources.
A part dans le cas tordu où ton disque dur/système est très lent à la création de fichiers mais sait les ouvrir et lire correctement, et que ton executable test l'existence de fichiers et les crée le cas échéant, il sera plus rapide à ouvrir&lire dans le premier dossier qu'à executer et créer les fichiers dans le second.
Enfin personnellement, je n'y crois pas du tout^^

Tu peux t'en assurer en exécutant le fichier dans son répertoire de compilation en ligne de commande.

[Tenebrous]

Effectivement, je confirme, j'ai essayé et c'est toujours aussi lent quand même.
Bref, je ne comprends vraiment pas cette différence (assez énorme qui plus est)...

[Obsidian]

C'est probablement dû à des choses très subtiles, comme des race conditions. Depuis l'IDE, il est possible que le débogueur préempte suffisamment souvent le processus pour le débloquer. Donc, sans voir ton code, ça va être dur de t'aider.

[Tenebrous]

Le problème est qu'il s'agit d'un projet entier !
Je me vois mal poster plus de 5000 lignes de code sur le forum (et je vous vois mal tout lire ^^).

[LittleWhite]

Bonjour,

Faites une analyse du code vous même. Dans le sens, soit vous utilisez un profiler, soit vous rajouter des morceaux de code pour chronométré chaque fonction. Ainsi vous serez d'où cela vient et donc vous pourrez nous poster un petit code (à moins que vous ne trouviez votre problème avant même de revenir ici )

[Tenebrous]

Le programme me sort justement un fichier de log avec toutes les actions effectuées ainsi que le moment auquel elles ont été effectuées (je vois donc l'évolution au fil du temps).

Le problème ne semble pas venir d'un quelconque blocage dans le programme. Quand je compare les deux fichiers de logs (celui généré en exécutant le programme dans l'IDE et l'autre en dehors), les valeurs de temps sont plus ou moins identiques (en même temps ça va très vite) mais celui exécuté en dehors fait le boulot moins vite (de l'ordre de quelques centaines de millisecondes). Evidemment, ça semble minime mais comme le fichier de logs généré fait plus de 300.000 lignes, au bout du compte ça fait une énorme différence !

En résumé, il y a juste une différence de vitesse d'exécution des instructions qui, comme elle est répétée un très grand nombre de fois, fini par donner une différence importante à la fin.
Voilà ce que je pense (mais je n'arrive pas à comprendre pourquoi...).

[LittleWhite]

Dans les deux cas, est ce que le log est affiché au même endroit ?
Si vous désactivez le log, est ce que vous avez un gain et une normalisation de la vitesse du programme ?

[Obsidian]

Voilà ce que je pense (mais je n'arrive pas à comprendre pourquoi...).

Comme on te le dit, cela peut-être dû à n'importe quoi. Par exemple :

• Ton programme utilise-t-il plusieurs threads ou processus ?
• Ta base de données est-elle privée et tourne-t-elle sur ta machine, ou bien s'agit-il d'un serveur central distant ?

Dans ce dernier cas, même sur ta machine, il est possible que ce soit le réseau lui-même qui dispose d'un anti-flood et qui t'impose une pénalité lorsque tu fais trop de requêtes dans un laps de temps donné.

Comment effectues-tu tes requêtes ? Est-ce que tu ouvres et refermes le serveur à chaque ligne ? As-tu essayé de limiter les requêtes en récupérant plus de données à chaque fois ?

[Tenebrous]

Obsidian :

Ton programme utilise-t-il plusieurs threads ou processus ?
=> Non.
Ta base de données est-elle privée et tourne-t-elle sur ta machine, ou bien s'agit-il d'un serveur central distant ?
=> Il s'agit d'un serveur distant.

Même dans le cas où le réseau disposerait d'un anti-flood, qu'est-ce que ça change à mon problème ? J'exécute le même programme sauf que dans un cas je l'exécute à partir de l'IDE et dans l'autre je l'exécute via la ligne de commande. Le réseau ne m'imposerait pas un anti-flood dans un cas et pas dans l'autre, ou alors faut m'expliquer...
Sinon, non, je ne referme pas la connexion à chaque fois mais encore ici, je ne vois pas ce que ça change dans mon cas vu qu'il s'agit du même programme.

LittleWhite :

Tu as vu juste, je viens de me rendre compte qu'en désactivant les logs, le programme s'exécute de manière identique dans les deux cas. Merci beaucoup à toi, au moins maintenant je sais d'où ça provient. Par contre, pour expliquer pourquoi, je cale...

[LittleWhite]

Cela dépend, vous ne répondez pas à ma première question.

Sinon, je pense que l'EDI effectue une sorte de caching / buffering sur le fichier de log.

[Tenebrous]

Si par "Dans les deux cas, est ce que le log est affiché au même endroit ?" tu entends : sur les mêmes numéros de lignes (dans Notepad par exemple), alors oui.

[LittleWhite]

Je pensais que avec l'EDI, le log pouvait être affiché dans la console "output" ou des trucs du genre.

[Tenebrous]

Nous nous sommes peut-être mal compris sur ce point alors.
Quand je parle de log, je parle d'un fichier que le programme crée au fur et à mesure de son exécution et où il enregistre chaque action qu'il a effectuée.

[Obsidian]

Même dans le cas où le réseau disposerait d'un anti-flood, qu'est-ce que ça change à mon problème ? J'exécute le même programme sauf que dans un cas je l'exécute à partir de l'IDE et dans l'autre je l'exécute via la ligne de commande. Le réseau ne m'imposerait pas un anti-flood dans un cas et pas dans l'autre, ou alors faut m'expliquer...

C'est ce que je te dis plus haut : un programme hors IDE et autres artifices effectuant un certain nombre de requêtes à destination d'un serveur peut atteindre la limite au delà de laquelle ledit serveur impose un délai de grâce. Et le fait de faire tourner ton programme en environnement contrôlé comme un débogueur peut le ralentir suffisamment pour le maintenir en deçà de cette limite.

C'était flagrant avec les firewalls actifs que nos admins s'amusaient à mettre en place dans ma boîte, à l'époque. Un « ls » un tout petit peu trop long et ma connexion était blacklistée.

Cela dit, c'était possible mais peu probable dans le présent contexte, non pas à cause des symptômes, mais à cause des valeurs des délais.

LittleWhite : Tu as vu juste, je viens de me rendre compte qu'en désactivant les logs, le programme s'exécute de manière identique dans les deux cas. Merci beaucoup à toi, au moins maintenant je sais d'où ça provient. Par contre, pour expliquer pourquoi, je cale...

À quel endroit est créé et enregistré ton fichier de log dans chaque cas, et comment est-il exploité par ton programme ?

Comme l'a dit LittleWhite, il est possible que l'IDE fasse un buffering efficace de ton fichier, mais se peut également qu'en production, ton fichier se trouve sur un lecteur réseau, par exemple. Dans ce dernier cas, ça engendrerait effectivement une chute importante des performances.

Cause possible mais probablement pas applicable dans ton cas : la protection de certains volumes par du RAID logiciel. C'est ce que je fais sur mon /home, mais ça flingue les taux de transfert.

[Tenebrous]

Comme l'a dit LittleWhite, il est possible que l'IDE fasse un buffering efficace de ton fichier, mais se peut également qu'en production, ton fichier se trouve sur un lecteur réseau, par exemple. Dans ce dernier cas, ça engendrerait effectivement une chute importante des performances.

Dès que j'ai vu cette phrase, j'ai su que c'était ça ! Je n'y avais pas du tout pensé mais ça vient de me faire tilt ^^ Un gros merci à toi (et a LittleWhite aussi) pour avoir pris le temps de m'aider, grâce à vous j'ai résolu un problème (qui n'en était en fait pas vraiment un) bien embêtant.
Encore merci !

[koala01]

Salut,

Sauf cas très particulier dans lequel tu souhaites effectuer du profilage en dehors de ton IDE, la version debug ne devrait etre lancée que depuis l'EDI.

Dés le moment où tu veux lancer l'application d'elle meme, le mieux est de compiler une version release qui va, entre autre, supprimer tous les symboles de débuggage ainsi que tous les assert.

Non seulement, tu remarqueras un gain de performance sans doute substantiel (surtout sur un traitement de plus de dix minutes), mais tu éviteras de ce fait aussi une foule de problèmes potentiels qui seraient du à certaines variables d'environnement qui ne sont peut etre accessibles que par l'IDE lui meme