Problème extrêmement bizarre avec time() et printf() - Page 2

65535 sans flush:
user 0.198s, sys 0.003s

avec flush:
user 3.109s, sys 0.233s

fait par ssh, bon exemple ou le flush fait perdre un temps ENORME.

Au contraire !

real 0m3.702s pour test2
real 0m2.747s pour test1

(bien sur il faudrait le lancer 100x et faire une moyenne pour avoir un resultat fiable) mais le buffering n'est pas la pour rien, meme sur une console "rapide"

j'ai beau répéter, c'est stable, 0.2 s sans flush et 3.1 s avec

Godzil (./17) :
Et attention, stdout est "touché" mais stdin, et stderr le sont aussi !

Euh ?? j'ai toujours vu que stderr n'était jamais bufferisé par défaut ? (ce qui se justifie vu que si on écrit sur stderr le programme a des chances d'être dans un état instable).
D'ailleurs c'est toujours chiant que quand tu stoppes un programme ça ne flushe pas automatiquement tous les flux (bon en même temps c'est difficile de faire autrement, si tu le stoppes tu veux qu'il s'arrête tout de suite, mais bon)

OK, le buffering est légitime à distance.
Mais en local, bof bof. Les programmes qui sont ralentis par l'affichage passent le plus clair de leur temps à afficher et non pas à calculer. Ils sont sonc mal conçus ou ne sont pas fait pour être rapides de base. Bon, admettons, il existe quelques applications très spécifiques à qui ça profite. Au nom de ces quelques chieuses on a préservé un comportement contre intuitif. Il ne reste plus qu'un problème à régler : la documentation qui n'informe pas.

Heu, un programme peut etre concu pour ne pas afficher normalement, mais qui a besoin d'afficher pour débugguer par exemple..

Toute façon, PedroM fonctionne pareil, donc c'est standard.

Thi-> contacte Ulrich Drepper, c'est le mainteneur officiel de la libc. Il sera heureux d'intégrer ton amélioration de doc.

(sachant que ce n'est documenté dans aucune page man que je connaisse...)

Thibaut > C'est même pas juste une question d'être ralenti par l'affichage. Les entrées sorties de manière générale (i.e. sauf exception) sont bufferisées, pour des raisons de performances... Si tu redirriges la sortie vers un fichier tu auras également des performances meilleures sans utiliser fflush...
C'est pas une question de distance, c'est une question de coût général. Par exemple: Un accès disque de 4 Ko ou 4096 accès disques de 1 octet tu verras peut-être mieux la différence ? Affichage / Disque dur / Transmission à distance (réseau ou autre) c'est le même combat.

Un problème avec le \n sous Windows, c'est qu'il cesse d'être interprété comme un "flush" si la sortie standard a été redirigée vers un pipe (du moins, sous une certaine version de Visual). Je l'ai appris à mes dépens et ai été obligé de rajouter des appels explicites à fflush()...

Par contre, je ne sais plus sous quelle version de Visual j'avais testé.

Thibaut (./28) :
Pas de problème pour ajouter cette information importante. Mais comment savoir à qui s'adresser ?

Il faut contacter les mainteneurs de la glibc (le mainteneur principal est Ulrich Drepper) à travers leur bug tracker:
http://sources.redhat.com/bugzilla/

L'utilisation du printf n'est pas plutôt historique pour des raisons de compatibilités (mais comme dit dans ce topic, aussi pour des raisons de performances). Tout comme l'est char* au lieu de unsigned char* pour un caractère en C ?
Quoiqu'il en soit il est possible de créer une pseudo console pour changer le comportement de stdout... http://rmathew.blogspot.com/2006/09/terminal-sickness.html

Bon Thibaut, c'est super normal comme comportement, on a tous eu à faire à cette surprise un jour ou l'autre. J'ai envie de dire tu viens de le découvrir, bienvenue au club. Et on avance dans la vie.

je crois qu'il a bien compris, pas la peine de lui en refiler une couche

J'ai bien compris et tu confirmes effectivement qu'on est nombreux à ne pas attendre ce comportement. CQFD.

éventuellement si c'est pour continuer en dialogue de sourds, autant laisser ce topic en paix jusqu'à ce que quelqu'un ait une contribution utile à apporter ?

merci.

Je pourrais continuer avec l'anecdote d'un copain qui refusait d'apprendre a utiliser DDD (meme si cest visuel pour le coup), il preferait faire ses printf avec \n pour debugger...

... jusqu'au jour où on a du coder un processus qui a une taille maximale de pile de 0 octet pour le projet de systeme d'exploitation. La il a du lancer DDD pour la premiere fois de sa vie.

les printfs pour debugguer sont tres bien, je connais des gens qui on codé un OS sans pouvoir utiliser de debugguer et ce pour plein de raison, et tu as pas le choix, printf sinon rien

t1, vous êtes quand même des trolls à haut débit

Bah quand on a free... on a la plus grosse.. ha non pardon, c'est pas ça le slogan

c'est pas loin

ceci dit je débugge aussi au printf (enfin, au syslog, mais spareil)

et vraiment en cas de grosse merdasse style segfault de derrière les fagots ou thread qui jardine chez le voisin, je sors gdb en ligne de commande, et là mes collègues habitués au débogueur de visual studio me regardent avec une horreur mélangée de respect, parce qu'ils savent pas s'en servir (c'est un débogueur ce truc? elle est ou l'icone breakpoint? O_o)

En meme temps gdb est particulierement... mal foutu

si peu

Godzil (./49) :
les printfs pour debugguer sont tres bien, je connais des gens qui on codé un OS sans pouvoir utiliser de debugguer et ce pour plein de raison, et tu as pas le choix, printf sinon rien

=>

onur (./48) :
... jusqu'au jour où on a du coder un processus qui a une taille maximale de pile de 0 octet pour le projet de systeme d'exploitation. La il a du lancer DDD pour la premiere fois de sa vie.

la il ne pouvait utiliser que le debugger et pas le printf.

squalyl (./52) :
et là mes collègues habitués au débogueur de visual studio me regardent avec une horreur mélangée de respect,

LOL

Quel est le plus pratique entre GDB et DDD ? J'ai été contraint d'utiliser un débugguer à un moment pour un gros souci dans mon projet, j'ai choisi DDD mais j'ai trouvé ça très mal foutu.

Ben y'en a un en ligne de commande, l'autre pas... Ça t'aide dans la résolution de cette question existentielle ?
Pour être plus exact faudrait préciser aussi que l'un des deux est un front-end pour l'autre mais ça gâcherai tout le jeu.

Donc GDB n'a aucun intérêt pour qui a la possibilité de lancer DDD ?

Si car pour utiliser DDD il faut savoir utiliser GDB

Thibaut (./56) :
Quel est le plus pratique entre GDB et DDD ?

Insight.