Reprise du message précédent :
ce détail que tu élude montre que ce que tu raconte est faux, désolé pour toi..
 
ce temps perdu à affecter compense simplement la rapidité du foreach
 
au final, pour faire le même nombre d'itération, les 2 solutions sont soit aussi rapide (peu de lignes) soit mysql_data_seek() est plus rapide (sur beaucoup de lignes)
 
t'as qu'à tester puisque t'es tellement un roxxor

 
Anthologique, celle là
 

 
delta1 = 0.017028
delta2 = 0.017603
delta3 = 0.020106 : avec l'affectation
delta4 = 0.002808 : en utilisant le tableau au lieu de parcourir les enreg avec mysql_fetch
 
Voila, tu peux aller te cacher
 
Au final : TOUTES MES EXCUSES : c'est "seulement" SIX FOIS PLUS RAPIDE
 
Serieux, je supporte pas ces mecs qui te contredisent alors qu'il n'y connaissent rien de rien.

tu continue à me montrer qu'un foreach est plus rapide pour parcourir un tableau, et ça on le sait depuis un moment..
 
pour parcourir 2 fois le tuple, t'es bien d'accord qu'il faut soit
 
1 - fetcher  
2 - remettre le pointeur à zéro
3 - refetcher
 
ou
 
1 - fetcher
2 - affecter un tableau (pendant le fetch, sinon tu va encore me sortir ça de n'importe où)
3 - parcourir le tableau
 
ton truc mesure pas la différence entre les 2 façons de faire..
 
moi si j'ai ça  
 

 
qui est plus lent que ça :
 

 
et pas 6 fois plus rapide comme tu le prétends..
 
 

Continue de t'enfoncer, ça me fait marrer  
 
avec un while au lieu d'un foreach :
 

 
delta1 = 0.017017
delta2 = 0.017053
delta3 = 0.020535
delta4 = 0.002854
delta5 = 0.00269
 
C'est encore plus rapide

 
oui / non pour parcourir X fois un tuple ?

'tain le dialogue de sourds...
 
smaragdus> c'est (delta1+delta2) qu'il faut comparer à (delta3+delta4), dans ton truc, non?
 
sh@rdar> ça doit dépendre d'un paquet de paramètres, tout ça, de toute manière...
 

à chaque fois j'y ai droit
 
tout ce que je veux, c'est qu'on reconnaisse que ce putain de bench est foireux
 
et effectivement si tu dois fetcher 75 fois les lignes, vaut mieux charger un tableau, mais pour les quelques cas pratiques que j'ai pu voir, mysql_data_seek() N'EST PAS LOURD ET LENT comme j'ai pu le lire

 
Venant d'un mec qui fait des bench avec des echo au milieu, lol quoi
 

non

 
 
réponds déjà à ma question précédente, on avancera un peu
 
parce que ton truc là t'as raté des additions on dirait..
 
delta1 = 0.017028 <= compte le temps que prend un fetching mysql
delta2 = 0.017603 <= compte le temps que prend un fetching après remise à zéro du pointeur
delta3 = 0.020106 <= compte le temps que prend l'affectation d'un tableau pendant un fetching
delta4 = 0.002808 <= compte le temps que prend le parcourt d'un tableau avec foreach

Ouais enfin en attendant tu testes pas la même chose que lui donc bon

 
 
de toute manière je suis d'accord avec ce qu'il compte lui un parcourt de tableau est bien plus rapide qu'un fetch ça fait un moment que je le répète

Je sais bien, je les ai lus tes posts

 
Bah si, je suis d'accord avec lui, là, c 'est le temps premier parcours + second parcours qui est intéressant, pas le temps du premier isolé ou du second isolé...
 

 
tu persistes
 
et oui et on en déduit que si tu veux parcourir 2 fois tes lignes :  
* avec ta méthode, ça va prendre 17 ms + 17 ms
* avec ma méthode, ça va prendre 20 ms + 3 ms
 
DONC ma méthode est  plus rapide et moins lourde (car la tienne laisse ouverte la connexion en plus)
 
CQFD.

 
 
si tu faisais un vrai test (les 2 méthodes séparées par exemple) et si tu veux on ajoute une coupure de connexion, comme ça tu verras qu'en plus tu peux lire le buffer en étant déconnecté

 
j'ai fait un vrai test (pas comme le tiens qui est foireux et mal fait)

On progresse, je sais pas si t'as remarqué mais t'es déjà passé de "ta méthode est 8 fois plus lente que la mienne" à "ta méthode est 50% plus lente que la mienne"

 
 
on va finir par y arriver, en plus de ça on a même transformé un CQFD en DTC

 
donc pour la connexion ouverte tu t'écrase gentillement c'est bien ça ?

il est foireux ton bench Smaragdus !

Apprends à lire

 
Apprends à lire, j'ai pas parlé de méthode mais juste pour la boucle en elle même, essaie de te rattraper aux braches comme tu peux
 
ta méthode foireuse et lourde :
 

delta1 = 0.017247
delta2 = 0.017484
delta = 0.034731
 
Ma méthode :  

 
delta1 = 0.02134
delta2 = 0.00559
delta = 0.02693
 
CQFD et DTC
 
Je ne pensais pas qu'on pouvait totaliser un tel niveau d'incompétence

ahh !! on arrive enfin à des résultats sérieux, t'auras pris le temps
 
array_pop fais effectivement gagner un peu de temps, mais ça ne t'aurorisera qu'une seule itération
 
maintenant compare sur 10 100 1000 10000  et1000000 lignes, et tu pourra juste arrêter de dire que c'est lourd et lent

 
Alors tu m'expliques comment tu arrives à tes résultats foireux où c'est plus lent avec le tableau ?
Tu n'esquives pas très bien    
 
Et j'ai utilisé array_pop mais j'aurais pu utiliser next(), t'es vraiment la mauvaise foi incarnée
 
C'est donc lent et lourd, cqfd
 
edit : et je prépare ton prochain argument de mauvaise foi: j'ai précisé dès le début qu'il fallait stocker en mémoire "si c'était possible"  
 
Quand j'avance qqc, je sais de quoi je parle MOI  

 
attends coco, t'as mis 2 pages pour mesurer correctement avec des partout et c'est moi qui suis de mauvaise fois
 
on sait même pas combien t'as de ligne dans ta table, tu dépile ton tableau donc tu pourra pas le reparcourir au besoin mais t'en reste à pinailler sur quelques ms alors qu'au début c'était ultra lent hein
 
 
et les résultats sont issus du code que j'ai mis plus haut.. testé sur une base de plus de 2 millions de lignes

 
C'est pas de ma faute si tu fais exprès de comprendre de travers.
Mais ça n'enlève rien au fait que c'est lent et lourd, hein, monsieur-qui-fait-des-bench-avec-des-echo ?

 
 
clair, echo c'est quelque chose qui n'est jamais utilisé dans des conditions réelles  
 
désolé coco mais ça me semble autrement plus réaliste que ton truc synthétique..

(en attendant sur le coup c'est lui qui a raison...comparer ce genre de trucs en collant des echo au milieu c'est ridicule.)

'tain mais tu peux pas arrêter tes vannes à 2 balles ? Shardar il reste poli sur 2 pages et toi tu passes ton temps à balancer des "t'es trop nul, lol ", t'as toujours pas compris que c'est toi qui passes pour un con depuis tout ce temps ?

 
T'as raison l'objectivité n'est pas de mise quand on veut se rattraper aux branches
 
En tout cas, tu auras bien fait marrer mes collègues de boulot à vouloir me certifier que manipuler des données en mémoire est toujours plus lent que les manipuler dans la database
 
Elu boulet du jour

 
M'en branle, passer pour un con auprès de tocard est un délice de fin gourmet

 
 
et en quoi ça change la mesure si on fait exactement la même chose des deux cotés ?
 
faire un echo va pas prendre plus de temps d'un script à l'autre, manipuler des données dans le vide c'est pas très logique..

masi faites du flash putain

 
t'as pas compris ma métaphore du poussin ?

 
ça ne "change" pas la mesure, mais ça change son ordre de grandeur, de rajouter des conneries au milieu de la partie intéressante...ce qui a tendance à minimiser les différences éventuelles...
 
Puis de toute manière, on traite les donnée d'abord, et on les affiche après, on ne mélange pas.

 
contrairement à toi je certifie rien, j'ai juste dit que mysql_data_seek et pas lourd et lent (me semble que c'est bien rentré là hein ? tu gratte quelques ms sur des boucles à vide et ton refus de faire un vrai test sur plusieurs lignes etc montre bien ta bonne volonté)
 
et pour le coup de la mémoire, je veux bien que tu m'explique comment fonctionne le pointeur, surtout une fois qu'on est déconnecté

 
 
ok, mais si on parle justement de pas affecter des résultats en mémoire pour rien, faudrait peut être les traiter (afficher) sinon y'a pas de raison d'être de cette fonction...
 
si c'est pour afficher plus loin, t'affecte tout d'entrée de jeu, reparcourir le tuple devient inutile

J'ai fait ce code :

 
Test sur une table d'osCommerce contenant 2708 enregistrements.
 
Fonctions testées indépendamments (une fois f1, puis f2), avec xDebug (et donc pas avec vos microtime pourris ). Résultats :
f1 : 2900 ms
f2 : 3300 ms

 
oui qq ms qui font que la 2ième boucle est 7 fois plus rapide
Quand tu developperas des sites pros, tu comprendras un jour que la moindre ms est importantes

Bon sinon moi je veux bien voir les résultats de smaragdus
1) En fonction de la taille de la table.
2) En séparant les 2 méthodes dans 2 scripts distincts.
 

 
Tout à fait
C'est bien pour ça que ses bench sont foireux (hein, djebel qui prend le train en route )
 

 
en plus

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