Discussion :

[wonderyan]

Bonjours,

je suis très surpris de voir que lorsque j'execute mon programme en C fraichement compilé (sur une mandriva, avec gcc, sans options particulières), il met environs 10 secondes pour s'executer.

Et que si je le relance desuite, qu'il mette seulement 1 seconde!

Je ne suis pas un codeur fou en C, mais je pense avoir suffisement de bon sens pour qu'il n'y ai pas d'abberations dans le code.

Mais ça me laisse l'impression que j'ai zappé un truc. Mon programme utilise une API assez particulière de bioinformatique (ACNUC), une sorte de SGBD qui recherche dans des banques de fichiers en local. J'en traite les résultats très succintement puis ecrit tout en sortie standard formatée.

Avez vous déjà rencontré ce "phénomène"!!??!!
Avez vous une idée ???? ... ???

Je vous remercie bien fort d'avance

Yan

PS : tous devant TF1 ce soir

[Ksempac]

Hum...Comme ca, dans le vide, si ton programme utilise un SGBD qui tourne indépendamment et en continu, je pense que le responsable de cette "accélération" est ton OS.

Lorsque tu executes ton programme, il va faire appel a la SGBD, qui va demander a l OS de récuperer des données. Celles ci ne se trouvant pas en mémoire, l OS les charge depuis le disque vers la mémoire (processus lent). Puis le SGBD envoie les données vers ton programme qui les traite et quitte.

Si tu le relances de suite, comme la SGBD n'a pas arrété de tourner, et que peu d'applications ont eu besoin de mémoire entre temps, il est fort probable que la plupart des données soient encore en mémoire. La lecture disque n'est donc pas nécessaire, les données sont directement récupérées dans la mémoire qui est beaucoup plus rapide et ton programme récupere ses données beaucoup plus rapidement.

Cependant, comme je l'ai dit, cette hypothese n'est valable que si le SGBD n'est pas ton programme lui meme mais un autre programme indépendant. En effet lorsque tu quittes un programme, les pages mémoires associées sont libérées.

[wonderyan]

Oui voilà le truc c'est que c'est pas vraiment un SGBD mais une API en C de fonctions qui permettent de récuperer depuis une banque de fichiers des infos.

J'ai cette intuition que tout est en place dans la mémoire vive à l'execution suivante. Un collègue m'a dit que le cache du disque dure devait y être aussi pour quelque chose.

Mon programme génère quand même un fichier de 1,7M pendant ces 1s.

Du coup je me demandais si il n'y avait une possible optimisation là dessous? C'est assez mystérieux et puissant tout ça. Comme reserver "moi même" une zone de la mémoire contigue ou je sais quoi d'autre.

Bref!

Merci pour la piste

Yan

[Gruik]

Ca le fait pour tout sgbd... ou plus generalement pour tout programme faisant des acces disque.. forcément, l'acces disque c'est ce qui est le plus craignos pour les perfs

[wonderyan]

En fait il ne s'agit pas d'un sgbd type serveur, un processus qui tourne en tache de fond et qu'on solicite au besoin.

Ce sont vraiment que des fonctions performantes qui permettent d'acceder à des fichiers structurés en l'occurence sur mon disque dure.

Donc en fait cette API qui simule un SGBD "nait et meurt" avec mon executable.

Ce que je ne comprends pas c'est que lorsque je relance mon executable, normalement il refait les mêmes choses. Mon ordi ne sait pas, a priori, que j'ai déjà executé les même commandes auparavent et pourtant je passe de 10 secondes à 1 seconde bordel !!!!!??!!??!!
Mon ordi "comprendrait" qu'à la 2ème execution il est en train de refaire les mêmes taches et que du coup il s'économiserait un acces au disque pour directement utiliser le cache????

En plus ça a beau me torturer l'esprit mais ça m'interesse drôlement de pouvoir contrôler ce truc puisque j'aurais besoin d'executer ce programme séquentiellement (juste en changeant "un champ" dans mes "requetes").

J'en fait appel aux gouroux du hardware et du C qui auront la grâce de m'éclairer !

Merci aussi vous deux et désolé, c'est n'est pas aussi simple

Yan

[dj.motte]

Salut,

Ben c'est normal la mémoire cache se souvient de la première instance. On retrouve ce problème avec les applications java, lentes à démarrer, mais une fois installées, assez rapides.

A mon avis c'est plus un problème de hard-ware que de programmation...

[crocodilex]

PS : tous devant TF1 ce soir

Ah ouais !!! Il y a des cours de langage C sur cette chaine ??

[wonderyan]

TF1 non en plus j'ai regretté de leur faire de la pub! C'était juste un acces de baufitude pour l'OL qui jouait son "grand" match...

Pour le profiler je ne vois pas trop ce que c'est je vais checker ça la semaine prochaine.
Mais oui c'est systématique le 10 sec -> 1 sec. Si vous êtes curieux voici en gros l'algo en langage naturel. Le but est de fournir un service de mise a jour d'une base de donnée bioinfo en back office sur un serveur au taquet (pbil) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
pour tout ce qui a un champ X égal à "A"
   pour tout ce qui a un champ Y égal à "B"
      pour chaucun des 64 éléments Z possibles de chaque éléments Y
         parcourir la longue chaine de caractères (disons 2000, c'est de l'adn)
            rechercher une séquence de 4 caractères
            plus recuper d'autres infos relatives a ces éléments
            écrire ce qu'il me faut au format tabulé sur une ligne
 
=> avec au final un nombre de 7 qui varie de 18000 à 30000 (mais à 30000 l'écart est un peu moins réduit)

et donc j'envisage de prendre par paquet les X, les Y et les Z dans un tableau, les traiter ensuite puis les écrire aussi par paquets apres.
Mais en fait je me demande si le cache du disque dure ne le fait pas lui même (pendant le premier lancement de 10 sec je vois le témoin s'allumer tres brièvement et régulièrement...)

Merci les gars

Yan

[souviron34]

et tu peux pas les attaquer drectement, les fichiers ??

[wonderyan]

Ca me prendrait trop de temps de codage de réaliser un parseur en C !!!!!!!!!!!!!!!!!!!!!!
C'est terriblement galère, et je trouve la bibliothèque standard pas top pour ce qu'elle offre.
Chaque langage son domaine.
Je veux bien en perl mais alors c'est plus 10 secs que ça risque de mettre!
Non mais je me contente très bien de ce temps d'execution faut pas pousser mémé.
C'est juste si y'a moyen de faire 10 fois plus vite avec une belle astuce je prend.

Bon week end à tous,

Yan

[Lunixinclar]

Bonne remarque. Du code dédié sera probablement plus rapide qu'une API générique.
Ecrire un parser en C est très rapide ... Juste par curiosité tu pourrais montrer un mini-exemple de banque locale de fichiers? Si après vérification il s'avère que le prog est effectivement plus rapide qu'en passant par l' API, ça vaut le coup.