Reprise du message précédent :

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

Allez encore un petit effort et un peu moins de mauvaise foi et tu arriveras au bench qui compare les 2 boucles dans 2 scripts différents

on va peut être conclure ?

Les chiffres le disent, pour peu que les 2 whiles prennent le meme temps.

réponds à florentg ! En quoi il est bidon son bench ?

 
Je suis desolé, on ne peut rien y faire. Ca ne fait pas la meme chose, ton foreach parcourt un tableau des plus basique, le while appelle une methode à chaque iteration dont on ne sait rien du fonctionnement. Ce sont 2 choses differentes. Et ton tableau basique, il faut bien le remplir qq part. Donc il faut compter le temps de remplissage.
 
Ca ne va pas plus loin. Aucune mauvaise foi.

j'ai déjà répondu 15 fois

 
 
il va répondre pareil qu'avant
 
même avec une balance précise au dixième de gramme, peser un poussin dans un 38 tonnes permet pas de déterminer le poids du poussin , donc faut forcément bencher à vide
 
accessoirement, j'ai pas eu de réponse pour mon pointeur à cartes perforées qui fait rigoler ses collègues, ni sur combien de lignes il a testé, et les résultats sur d'autres recordset
 
mais bon, il a raison, il fait que ça de le répéter

 
Page 2 Posté le 16-05-2006 à 15:38:27    

euh non  

 
 
bencher print_r ne m'interesse pas

(oui enfin le truc intéressant dans son bench, c'est que ta solution était sensiblement plus lente, malgré le print_r, hein...)

 
sans blague ?

bon allez hop ! 4 pages de dédain, de ton hautain, de nombrilisme, et j'en passe... je t'avais prévenu l'autre jour sur un autre topic, manifestement tu n'en as rien eu à faire. TT jusqu'à vendredi, et c'est pas cher payé

 
Bah et c'est bien ce que l'on te dit. Ne bencher qu'une boucle ne sert à rien. Elles viennent d'où tes données???????

 
même chose pour le mien, et y'a aucun affichage
 
on peut gratter un peu car foreach() va refaire une copie du tableau, mais je persiste, ça bouffe de la mémoire pour un gain négligeable  
 
et la plus y'aura de lignes, plus l'écart va se creuser en faveur du pointeur mysql,
 
écart qui devrait logiquement diminuer (à voir dans quelle proportion) si on fait beaucoup de parcours du tuple puisque le trou se forme à l'affectation supplémentaire pendant le fetch

 
 
ah mince, t'aurais pu attendre, on aura pas les réponses

quelle réponse ? qu'il te dise que tu es un parfait incompétent, que c'est lui le plus fort et que vous etes tous des nuls ? c'est un rigolo c'est tout

Il a rien compris. On va répéter et surtout conclure :
 
Ca ne sert strictement à rien de bencher à vide. Il faut toujours bencher en utilisations réelle. Alors j'ai mis print_r, mais ce n'est pas non plus top, il faudrait bencher en conditions réelles, avec du vrai traitement.  
 
Bencher à vide est très dangereux, et conduit au principe de premature optimization, à savoir qu'on risque de perdre du temps à optimiser quelque chose alors que finalement l'optimisation ne représente rien au final.
 
Prenons notre exemple du poussin et du 38 tonnes. On veut que le convoit soit le plus léger possible. Alors on pèse deux poussins : l'un fait 120 grammes, l'autre 100. Selon notre ami smarzgafdurus, il faut prendre le poussin de 100 grammes parce qu'il est plus léger... Maintenant observons de plus près : entre un poussin de 120 grammes et un poussin de 100 grammes, va-t-on faire la différence sur une somme totale de 38 tonnes ? Vaudrait mieux changer le 38 tonnes que de prendre un poussin qui fait 20 grammes de moins qu'un autre.
 
Là c'est pareil : la différence d'exécution entre les deux méthode ne justifie pas d'en prendre l'une ou l'autre. Face à un traitement lourd, la différence ne se fera pas sentir. On choisira la méthode suivant ce que l'on veut faire, suivant l'architecture de l'application, et selon plein d'autres critères qui peuvent entrer en jeu.
 
 
J'me souvient y'a encore quelque semaines, dès que je voyais un echo "pouet";, cash je corrigeais en echo 'pouet', parce que c'est plus rapide avec des simple-quotes... Sauf qu'au final, bah y'a pas beaucoup de différence. Quand on jette plein de fonctions et plein d'accès aux données au milieu de ces echos, ce n'est pas des simple ou double quotes qui feront la différence. Résultat, j'utilise maintenant souvent la version double-quote, il m'arrive même d'y mettre des variables dedans Est-ce que ça a plombé mon script ? Réponse : que dalle.
 
 
Conclusion finale : développez votre application, programmez des tests unitaires. Une fois que ça fonctionne, profilez l'appli, chercher là où c'est lent. Refactorisez (les tests unitaires permettent ici de pas se planter), rebenchez. Répétez jusqu'à ce que vous ayez atteint un certain objectif de performance.

 
temps d'exécution moyen : 0.410s (avec 18000 posts dans la table).
 

 
temps d'exécution moyen : 0.450s (avec 18000 posts dans la table).
 
Bref la seconde solution est plus lente dans ce cas (PHP 5.1) que le mysql_data_seek... Donc faudrait revoir tes benchs dans lesquels soit disant le data_seek est huit fois plus lent...    
 
Ceci dit, la mauvaise programmation c'est ici de parcourir deux fois le tableau si tu veux mon avis...
 
Et je pense aussi que de créer un tableau pour ne le parcourir qu'une fois alors que les données sont déjà stockées, c'est une connerie, m'enfin bon...
 

 
En plus tu t'enfonces, de mieux en mieux ^^
 

 
Allons-y gaiement réviser la doc ^^ tu viens avec nous ?
 

 
Tu as raison    mais bon il s'entête, faut qu'il vive ses rêves  
 
En plus il a toujours pas compris que dans le foreach il assigne un tableau qui ne sert à rien, et qui fait donc perdre du temps...
 
Smaragdus est donc un bon boulet  

putain, quand je pense que je t'ai écouté, et que depuis j'utilise que des simples quote    
lol

L'arroseur arrosé

 
sur le pointeur interne et la mémoire
 
le reste on savait déjà (et rigolo tu reste gentil, j'aurais bien quelques autres qualificatifs)

Haha, d'où l'importance de savoir se remettre en question

 
j'ajouterais juste qu'il faut éviter de balancer des choses comme étant des vérités, surtout si on a pas le ton qui va avec
 
sinon, ça reste utile pour certains cas, dans le mien des stats ecommerce, on récupère les sommes de tout un tas de colonne en une seule requête, et on reparcours plusieurs fois le recordset pour travailler sur quelques colonnes (CA / panier moyen / nombre d'articles / totaux fdp etc etc etc)
 
ça marche bien, et un gros script comme ça bouffe déjà largement assez de mémoire, donc je suis resté sur le pointeur

concluez, concluez, profitez en

C'est fait

Je propose de renommer le topic en : " Sh@rdar le roi de la patience" et de closer

 
 
je suis la zenitude incarnée, ça te fera ça aussi quand t'auras des mômes

j'ai déjà harko à m'occuper et c'est déjà pas mal

Bordel, si élever des mômes c'est encore plus chiant que l'autre avec son ton méprisant, spa demain la veille que j'm'y mets

et moi qui esperait voir bientôt une portée de taiche courir dans les champs avec leur gros doigt rouge ..

 
 
bin le problème c'est qu'ici tu peux pas hurler "monte dans ta chambre" ou lui coller une fessée

Mais quand on a le choix autant mettre le poussin de 100 gramme hein, si ça ne nous coute rien de plus que celui de 120g...
c'est comme pour les echo 'test'; ou echo "test"; , autant mettre des simple quotes que des double quotes, ça ne nous reviens pas plus cher, c'est con de mettre des doubles quotes sachant que les simples sont plus adaptés si ça ne nous apporte pas un plus

oh ouiiiiiiiiiiii  
 

                                               
                                                                                           
                                                     

Biens-sûr, mais entre choisir de mettre un poussin de 100 grammes ou de refaire toute la structure du poids lourds en carbone, le choix est vite-fait. Pour les simples quotes, le problème est relativement simple, c'est un choix qu'on peut faire vite-fait lors du développement. Par contre pour notre cas, où la différence n'est peut-être pas directement perceptible, vaut attendre que l'appli soit torchée

ouais mais le faire uniquement pour l'optimiser ça reste de l'enculage de mouche quand même
 
sinon autant foutre tout le code sur une seule ligne sans commentaires pour gagner quelques octets

Voilà Vaut mieux un vagin que quinze anus de mouches

On parle pas de refaire quelque chose d'existant mais d'ajouter un truc  
Donc quand on ajoute autant utilise le truc le plus light si on le connait au lieu de faire ça à l'arrache en se disant que de toute façon, le truc global est moisis donc on est pas à ça près... peut être que si on réduit la structure de 38tonnes à 1kg (ouai si on est très fort   ) bah là les xx grammes non gachés seront sensibles