Reprise du message précédent :
Maintenant, en conditions réelles, on utilisera plutôt f2 : La couche DB récupère le résultat et retourne un tableau, sinon on se retrouve avec des instructions mysql dans la présentation

 
 
en attendant tu m'explique pour le pointeur ?  
 
(t'as quand même l'art d'éviter les questions qui gènent hein )
 
EDIT : et on s'en fout de mesurer qu'une partie, ça vaut rien de rien, tu pige pas ?

 
Il a mis des print_r
 
Un conseil : essaie avec des sleep(10000) à chaque boucle tu verras qu'il y a encore moins de différence

 
C'est ce que j'ai un peu plus haut    

 
Rapport avec la choucroute : nul
 
Au fait t'as toujours pas expliqué pourquoi ta base données est plus rapide que la mémoire ? T'as des cartes perforées ?

T'as oublié "gros incompétent de merde" à la fin de ta phrase

 
 
et sans affichage mais avec 10, 100 et 1000 lignes ?
 
chez moi  
 

 
reste plus lent que
 

 
pourtant, aucun affichage rien, comment t'explique ça

>djebel qui prend le train en route
C'est pas parce que je débite pas 50 insultes par pages que j'ai pas suivi.
Le test de FlorentG montre bien que tu es bien trop sûr de toi, et quand bien même tu aurais raison ça te permets pas de faire le connard.
(jle mets en gras hein avant que tu te mettes à contester tout ça tout ça).
 
Ca me fait penser à ces prestataires qui débarquent dans des boîtes en croyant tout savoir de la vie, et en te traitant comme le dernier des connards parce que ton code est pas optimal, alors que ce n'est pas le tien, ou alors c'est une consigne de ton con de patron, etc ...

 
Euh là je lis recuperation du recordset + affectation dans un tableau + parcours du tableau donne 0.020106+0.002808=0.022914
Ce qui donne plus que le parcours du while uniquement

 
 
tu parle de base, pourtant mon second fetching je le fais déconnecté, donc je répète, de où sortent ces résultats ? (DTC proof)

 
spa le genre de la maison, je laisse ça à masklinn  

 
Je quote l'insulte et attends ta sanction avec joie    

si faut être banni pour te dire que tu tapes sur le système de tout le monde, et que tu pourrais dire la même chose sans faire ton kéké, np

 
La metaphore n'est pas bonne. Si le camion reste le meme et que la balance est precise peu importe le poids que l'on rajoute à celui des poussins, le delta restera le même.

Pourquoi ? Parce qu'il y en a un qui utilise un fonction de l'API (donc en C), et l'autre qui est basée à 100% sur PHP (donc interprété et full ramage). Sans parler de l'initialisation du tableau de rows, qui lui aussi prend beaucoup de temps dans le second cas. Vaut mieux réutiliser la mémoire (double mysql_truc) que de se taper un tableau complet à remplir.

oui, mais il paraitra ridicule.

 
Tout ça parce que j'ai raison

 
bin ouais, ce qui fait que je vois pas pourquoi un affichage ou autre chose changerait le temps d'écart

oui mais le rapport sera proche de 1, donc forcément ça semble minimiser l'effet  

si en quelque sorte ca va changer, c'est qui si tu pesais les 2 poussins dans 2 camions differents, même modele mais differents. On est pas sur qu'ils fassent (camions) précisement le même poids. Tout comme tes echo n'ont pas tous la mm durée d'execution.
 
Ceci dit je ne vois pas l'interet de faire un while des resultats pour les affecter dans un tableau, puis de lire ce tableau plus tard. A moins d'en avoir besoin plusieurs fois dans l'execution du script ca ne sert à rien. C'est pourquoi je n'arrive pas à comprendre la mesure d'un foreach seul.  Sans l'alimentation du tableau il ne fera rien

Parce qu'en pratique, si ton application est bien torchée, tu as un minimum d'abstraction vis-à-vis de la source de données. Hors de question de mettre des mysql_fetch_row lors de l'affichage par exemple.

>Tout ça parce que j'ai raison
 
- le fait que tu aies raison n'apparait clair qu'à toi seul.
- que tu aies raison ne me dérange en rien
 
Dans le test de florentG, y a pas de rapport, il a mis des print_r aux deux tests, il n'y a donc aucune différence entre les deux méthodes due à ce print_r.

Encore faut-il que le protocole de mesure soit bon.

Regarde le test de florentg juste au dessus de ton post

Ouais mais sur le fond smaragdus a quand même tord  
 
(Et on peut être propre en wrappant l'appel DB dans un itérateur, comme ça on a jamais d'instruction mysql dans la view et on a pas non plus à créer un tableau complet )

Je suis d'accord, je ne dis pas le contraire. Mais ce n'est pas plus rapide comme methode. Le temps du foreach s'additionne obligatoirement à celui du while. Quelque soit la methode, il faut bien extraire les données du recordset.
 
Je precise que je parle du bench.

Ca montrerais une chose : que les deux méthodes finalement ne valent pas grand chose par rapport à ce qu'il y a dedans. Si tu mets des sleep(10000), tu verra très peu de différence entre les deux. Conclusion : on s'en fout laquelle méthode est la plus rapide, vu que c'est le sleep(10000) qui pose problème.
 
Si on ne met rien dans les boucles, évidemment on va trouver de grosses différences en temps d'exécution. Mais dès qu'on met un peu de traitement là-dedans, bah finalement on remarque qu'on s'en fout de la méthode, ça devient à peu près similaire.
 
C'est comme ceux qui font la différence entre print et echo (je faisais partie de ceux-là, mais plus maintenant). Alors pour 10 000 itérations, on remarque que echo est plus rapide que print... Mouais, pour 10 000 itérations. Mais dès qu'on les places dans une grosse appli avec accès aux données et tout, bah c'est pas l'utilisation de print ou de echo qui fera la différence niveau perfs.

Effectivement, et tu viens d'ailleurs de me donner une idée
 

Voilà

bench foireux
 

 
tort    
Et les benchs prouvent que j'ai raison

Ca me rassure, je commencais à bruler tous mes codes sources pour incompetence complete. J'avais commencé a rediger ma lettre de demission.
 
Ouh là, je reponds à Florentg, hein!!!!

En quoi ils sont foireux
 

 
Non mais serieux, tu n'as toujours pas vu ton erreur dans tes deltas de mesures

Explique en quoi c'est foireux

 
lis le topic plutôt que de débarquer avec tes gros sabots

C'est marrant, tous les benchs que tu ne fais pas sont foireux et les seuls benchs montrant que tu as raison sont les tiens

parce que j'ai raison
Parce que je bench les bonnes choses (mysql_fetch) et pas des print_r ou des echo

Perso je pars du principe que seul contre un je peux supposer avoir raison, seul contre 5 pourquoi pas (je suis le meilleur). Mais seul contre tous, je commence à avoir de serieux doutes.
 
Mais peut-etre que je ne comprends pas bien l'objectif de ton test.
 
Je suis d'accord qu'il ne faut rien rajouter d'autre que le necessaire dans le bench. Mais c'est bien le seul point où je suis d'accord.

c'est pas parceque j'ai pas posté que je suis pas le topic
Donc vas-y réponds à la question(que floretg aussi t'as posé)

Non. Tu fais l'erreur de bencher sans traitement dedans. Ca s'appelle enculer les mouches pour gagner 0.0003 ms sur le total de l'exécution.

Premature Optimization, ça te dit quelque chose ?

 
Moi ce que je vois dans son bench c'est:
 

• Je calcule le temps d'un parcours de recordset
• Je calcule la meme en y rajoutant le data_seek, histoire de montrer le surplus de temps généré par le data_seek
• je calcule l'affectation dans un tableau du recordset par un while
• je calcule le parcours à vide de ce tableau avec un foreach

Le probleme est que 2 premiers while et le dernier foreach ne font pas la même chose. Le foreach ne recupere rien dans le recordset contrairement aux whiles. C'est comme comparer le poids d'un cochon et celui d'un moustique dans un 38 tonnes

L'histoire ne dit pas que mysql_data_seek ne génère strictement aucun surplus