[Résolu] Allocation de mémoire... ?

[Sephi-Chan]

A mon avis tu es surtout sur la voix du gros n'importe quoi. Sans vouloir être méchant, tes optimisations sont juste drôles. Je serais curieux de voir un peu ton code. Peux-tu coller un fragment de code s'il te plaît ?


Sephi-Chan

[MaXOhBalle]

Quantités de méconnaissances et d'approximations dans ce fil de discussion. Sincèrement, arrêtez de vouloir couper les cheveux en 4 ! On fait ça quand on a une parfaite connaissance des méandres d'un langage, et au moins une application déjà totalement fonctionnelle...

Là on dirait une discussion d'experts dans une série télé :?

Et comment on fait pour avoir "une parfaite connaissance des méandres d'un langage" ? Ah oui... On se pose des questions comme je l'ai fais tout au long de ce post... On ne devient pas "expert" d'un coup de magie.

Après, je ne connais pas la valeur exacte des réponses.

---

A mon avis tu es surtout sur la voix du gros n'importe quoi. Sans vouloir être méchant, tes optimisations sont juste drôles. Je serais curieux de voir un peu ton code. Peux-tu coller un fragment de code s'il te plaît ?


Sephi-Chan

Méchant ? tu l'es.

Tu ne connais même pas mon projet, ni les connaissances que j'ai dans d'autres langages et tu me traite comme un amateur "idiot"; tu me juges quoi (déjà hier j'étais pas mal vexé du "ridicule" et de l'"absurde" de mon questionnement (d'après vous), là ça commence à être lourd l'air "moi je connais tout, toi rien")

Je commence à en avoir assez de ce post et de vos réflexions.

Je retransmettrai un bout de mon code et mon projet en globalité quand j'en aurai le temps (je l'ai pas encore présenté dans "Vos projets"), mais vous me donnez sérieusement plus envi depuis hier.

Merci, salut. Sujet résolu.

[Sephi-Chan]

Tu te braques parce qu'on trouve ton questionnement alambiqué… Tu sabordes ton sujet tout seul en ne donnant pas ton contexte…

Je ne te considère pas comme un idiot amateur, ni ne te juge, j'attends simplement de voir un bout de code qui utilise ça. Tu poses des questions sans donner les moyens de te répondre. Ce qui sera vrai dans un cas ne le sera pas forcément dans tous.


Sephi-Chan

[pascal]

keep cool les gars

Ce qui est décrit est une structure à tiroirs, les tableaux sont faits pour gérer ça.

L'important c'est d'avoir un code lisible, c'est à dire facile à débugguer et à faire évoluer.

Concernant les performances, ça n'est visible que pour de très très gros volumes, qui ne seront jamais atteints (beaucoup de varibles / beaucoup de trafic). Des optimisations sur la base de données ou le cache sont plus rentables.

A+

Pascal

[QuentinC]

Les tableaux sont là pour ça, et ils sont plus simples à manipuler, je ne vois pas pourquoi il ne faudrait pas les utiliser.
En plus, les variables variables, c'est pas clair et pas naturel, amsis c'est une question de point de vue. Perso, je réserve les variables variables, call_user_func et autre eval seulement quand il n'y a vraiment pas d'autre solution. Ca reste pratique à l'occase, mais pas à la place de structures plus adaptés.

A part ça, ne vous tapez pas dessus s'il vous plaît, merci. Là, tu te self auto-suicides toi-même tout seul.

[wild-D]

je suis pas d'accord que le questionnement est alambiqué. Coder "écolo", pour moi est une bonne pratique; l'usage intempestif de méthode industrielle à tout va sans reflexion c'est pour moi encore plus alambiqué.

Franchement y a rien de plus utile que d'être capable de remettre en question ce que l'on sait ou ce qu'on croit savoir.

--
je crois que naholyr faisait référence à des remarques erronée style la comparaison de '.' et ',' comme opérateur de concaténation: ',' n'est pas un opérateur de concaténation (le fait de le comprendre est important)

interpréter correctement ce que tu code et dans quel contexte est important; cela permet d'évaluer correctement les choses. (rien emp^che de faire un test pratique derrière pour s'en assurer).

--

tu te rends compte quand même que tu es en train de parler de pouième je pense. C'est important de s'en rendre compte vis à vis d'autre élément comme le temps d'accès à une bdd, le temps d'exécution d'une requête, le changement de ta config php, ou du serveur, sans parler de modif d'OS ou de matos. Tu ne dispose pas d'un temps infini, donc faut bien donner des priorité à chaque élément.

Si tu considère que tu as un potentiel avantage à tenter de gagner ses pouièmes malgrès le temps et les efforts que ça va te couter, soit.

perso ma reflexion est simple:

$var vs. $array['var']
une var directe, s'est plus rapide qu'un accès par tableau (mais bon c'est vraiment minim-minime, le passage par réf de tableau on peut difficilement faire une opération plus légère^^ quant à la ram la différence doit pas être énormisime, surtout si je compart à tout le reste)

bon sauf que dans mon programme j'aurais besoin d'un truc un peu plus dynamique,
$$var vs. $array[$var]
bon on est p-e monté d'une catégorie, mais honnêtement une variable dynamique contre une réf dynamique d'un tableau, je sais même pas lequel est le plus rapide, mais si un est plus rapide ça doit pas tenir à grand chose.

bon pour continuer ma conception j'ai besoin de pouvoir avoir des référence "multidimensionnel", genre
${$var1.$var2} vs $array[$var1][$var2]
oulà y un nouveau gus dans la danse '.', ou une opération de concaténation... ou là je crois qu'on vient de passer à une catégorie supérieure d'un coté du ring.
et ça doit pas s'améliorer avec du:
${$var1.$var2.$var3.$var4} vs $array[$var1][$var2][$var3][$var4]

accessoirement $array[$var1][$var2], si le contexte s'y prête, y a p-e des occasions ou je pourrais passer par un truc plus light genre $var1[$var2]. Si s'agit juste d'une manière élégante de regrouper mes vars par "famille".


pour le reste: niveau env de dev: ben mon IDE, c'est kif-kif. pour mes mimines, les points c'est cool, crochets ou accoladde c'est pareil, y a plus de crochets, mais bon c'est pas ça qui va peser lourd.


dans les à coté, PHP offre count(), array_*, foreach(), list() etc... gros avantage aux tableaux.


bon si j'ai besoin de structurer mes données entre des tableaux ou bien un truc fait main avec des concaténations, moi je m'arrête là, mon choix est fait. (99% de chance que je sois toujours gagnant, sauf pour un script simple hello world je doute de faire une erreur-)

comment ça t'es pas encore convaincu ? Oo
si on se rappelle que les entrée c'est $_GET, $_POST, sans compter que les retour de bdd, ça passe généralement par des tableaux aussi (ou des objets)./note: global on c'est mal /
Le gros des input "interactif" pour moi c'est des tableaux. Tes vars elles pèsent quoi en comparaison de ces inputs ? Parce que dans mon esprit une part importante du besoin de dynamisme tient avant tout à l'interactivité. Je dis pas que je défini jamais de var dynamique, mais bon à coté, je sais aussi que c'est bien agréable d'avoir un tableau pour pouvoir passer leur référence de manière groupée (argument de fonction ou mot clé global).

maintenant à toi de voir ce qui te correspond le mieux et répond le mieux à tes besoins.

[Allwise]

Quitte à faire de si grosses concessions sur les outils / fonctionnalités d'un langage, autant descendre un échelon dans les niveaux et programmer directement en C.
A la louche, je dirais que le gain de perfs d'une appli PHP judicieusement portée en C tournerait dans les 3000 % ( 30 fois plus rapide )

[MaXOhBalle]

Excellente réponse Wild-D, c'est tout ce que j'attendais...

Allwise, je descendrais bien mais le langage est aussi bien plus complexe et programmer un jeu-web en C serait beaucoup plus délicat, prendrait plus de temps à faire etc. (c'est un peu le prix à payer de la performance, normal quoi).

Ainsi, je préfère apprendre à gagner des "pouièmes" facilement (sans autre travail sinon une méthodologie plus affinée au moment même où on programme) que passer encore plus d'heure à déboguer mon projet en prenant un langage bas niveau

J'ai publié mon projet entre-temps dans la section appropriée, j'espère que vous me donnerez vos avis si vous avez le temps

Merci à tous, à la prochaine.

[Gwym]

Si tu veux une réponse approximative pour le temps d'exécution, mets simplement les différentes méthodes dans des boucles de 10000 iterations, mesure le temps

Vu que finalement personne ne s'y est attelé... pour ma culture personnelle

ITERATIONS : 216000
ECRITURE
${'ma_variable_nommee_'.$x.'_'.$y.'_'.$z} = value; // 3 * 0..60
TIME > 0.4576
${'ma_variable_nommee_'.$x} = value; // 0..216000
TIME > 0.3042
$var[$x][$y][$z] = value;
TIME > 0.1814
LECTURE
$a = ${'ma_variable_nommee_'.$x.'_'.$y.'_'.$z};
TIME > 0.3339
$a = ${'ma_variable_nommee_'.$x}
TIME > 0.1718
$a = $var[$x][$y][$z];
TIME > 0.0934

(PHP Version 5.2.10-pl0-gentoo)

[NicoMSEvent]

Pour info, le langage Effeil (purement et 100% orienté objet) est précompilé (traduit) en C++, et est excessivement rapide par rapport a beaucoup d'autres langages (java par exemple).
Les avantages de Effeil par rapport au C++ sont les préconditions, postconditions, etc...