Parcurgere array

Salut!

Avem aceste 3 variante de parcurgere si modificare a unui vector:

//varianta 1:
foreach( $array as $key => $value ){
	$array[$key] = 1;
}
//varianta 2:
$keys = array_keys($array);
$sz = count($keys);
for($i=0; $i<$sz; ++$i){
	$array[$keys[$i]] = 1;
}
//varianta 3:
function f($n){
	return 1;
}
$b = array_map("f", $array);

Am avut o discutie cu cineva cum ca foreach in general e mai incet decat for, dar pentru modificarea elementelor din vector, array_map() e mai bun decat orice.

Ce argumente si contraargumente aveti pt fiecare dintre cele 3 variante?

Va multumesc!

Diferenta majora dintre 1 si 2 e presiunea cognitiva aditionala pe care o simti in cazul 2. La aceste cateva linii de cod nu iti dai seama, dar cand ai de-a face cu sute de mii de linii de cod scrise intr-un stil sau altul, incepi sa devii "sensibil" la astfel de detalii.

Din acest punct de vedere, 1 e de preferat fata de 2. Performata computationala (RAM sau CPU cycles) e irelevanta la astfel de "optimizari". Ergonomia codului e mult mai importanta. Continua sa citesti, iti voi explica de ce este asa.

Varianta functionala (3) e de preferat per total, generic vorbind, tot din perspectiva ergonomiei codului, in special daca ii dai un nume bun, descriptiv, acelei functii.
Daca faci un functional object (__call, evita __callStatic, ca acolo nu ai de-a face cu obiecte), poti "stoarce" din cod si alte avantaje arhitecturale ***.


Summa sumarum: evita microoptimizarile in astfel de cazuri in care nu ai de-a face cu algoritmi complicati. Nu adauga o valoare codului, ba din contra, sunt chiar o tinta falsa care deterioreaza mai mult calitatea codului. Continua sa citesti, iti voi explica de ce este asa (prima oara te-am pacalit).

Nota: intre noi fie vorba, suspectez ca cel cu care ai discutat despre 1 vs. 2 analiza problema din perspectiva C. Insa el nu pare sa fi luat in calcul arhitectura interna a lui PHP si structurile de date folosite intern. Foreach e mai rapid, deoarece se itereaza la rand, nu e lookup in hash table. DAR, desi repet: nu acesta e motivul pentru care 1 e de preferat in comparatie cu 2, ci ergonomia codului. Per total, tot varianta 3 e cea mai buna optiune, la modul general vorbind - continua sa citesti, iti voi explica de ce este asa (de data asta pe bune, te-am tot pacalit ca sa iti mentin creierul alert si deci atent la ce am de spus).

Nota: un alt motiv pentru care microoptimizarile sunt o tinta falsa e moore's law. Puterea computationala se dubleaza la fiecare doi ani. Asta inseama ca toate acele "optimizari" pe care le faci si care dubleaza performanta sunt amortizate in doi ani. Ironia e ca aceste microoptimizari nu dubleaza niciodata performanta, obtii maxim cateva procente de performanta in plus. Adica: suporti consecinte la ergonomia codului, cod pe care trebuie sa-l mentenezi de-a lungul anilor, pentru a obtine "beneficii" care sunt amortizate in cateva luni de zile. Efectele colaterale ale acestor microoptimizari mai mult dauneaza, costul creste, iar cel mai scump este developer time - caci exista o corelatie directa intre developer time si presiunea cognitiva pe care o exercita codul asupra creierului programatorului.


Suspectez ca nu e genul de raspuns pe care il asteptai. Astfel de comparatii gen 1 vs 2 vs 3 sunt ok ca jocuri de novici, insa am incercat sa-ti expun privirea de ansamblu a lucrurilor care conteaza cu adevarat daca vrei ca un proiect sa aiba succes.


*** daca esti baiat destept si ai inteles exact ce iti spun, ma vei ruga sa ma concentrez pe lucrurile care conteaza cu adevarat si sa iti povestesc despre acele avantaje arhitecturale

Edited by OriginalCopy, 09 October 2015 - 23:33.

Merci mult OriginalCopy!
M-ai lamurit!
Eu am cativa ani de Java in spate, si am cunostinte si de Javascript, Groovy, C etc.
Inteleg ce zici tu, despre code readability.
Cred ca cel mai mult m-ar fi interesat viteza fiecaruia.

Apropo, acum cateva zile am vrut sa optimizez niste cod.
O persoana (alta decat cea din discutie), mi-a spus sa nu il optimizez, ca mai bine mai cumpara un server sau 2.
Bine-nteles nu era vorba doar de o optimizare de genul asta. Era una ca lumea.
I-am explicat:
Daca el are 2 servere acum, si mai ia 2, atunci viteza de procesare se va dubla.
Dar daca are X MB de date in baza de date, si se vor dubla, atunci timpul de procesare se va mari de vreo 4-5 ori cel putin.
Deci cred ca in unele cazuri e mai bine sa scrii cod optim decat sa cumperi putere de procesare, pentru ca procesarea e cu atat mai slow cu cat creste numarul de elemente cu care operezi.
Scalabilitatea codului e mai ieftina decat serverele in cazul asta, pt ca costul serverelor necesare sa "acopere" lipsa de "developer time", cum ii zici tu, creste exponential fata de costul programatorilor. Parerea mea

Daca vorbim de code readability, nu ar trebui sa existe nici o variabila denumita $b, $sz etc cum sint in exemplul de mai sus.

Si evident nici o functie numita f(). Si variabilele ar trebui definite inainte, ca in Java, C chiar daca PHP nu cere asta (aceeasi recomandare si pt Javascript).

Intrebarea e pusa in sectiunea incepatori, totusi.

Daca vrei sa optimizezi pt viteza, de ce nu testezi viteza fiecarei variante? Poti face asta fie cu un profiler fie iti scrii singur un pic de cod cu microtime() si vezi rezultatele.

$start_timestamp = microtime(true);
...
---your Code---
...
$end_timestamp = microtime(true);
$duration = $end_timestamp - $start_timestamp;
error_log("Execution took ".$duration." milliseconds.");

Ca regula generala, codul mai curat si mai usor de citit, inteles, modificat, incorporat cu UnitTests e mai important ca micro-optimizarile, dar pot fi si cazuri particulare, desigur.

Mai poti testa performance ul si utilizand https://eval.in/, nu stiu daca stiai de el.

Mai e un aspect: performance-ul se poate schimba de la o versiune PHP la alta. Inca un motiv sa nu te preocupe f mult.

Mai concret un pic: loops (ca "for") sint constructs, si nu function calls cum e array_map, deci mai rapide.

@OriginalCopy, te intreb eu, ca vad ca OP nu te-a intrebat, despre avantajele arhitecturale, daca esti amabil sa mai scrii in continuare, ca e interesant.

Edited by maxtron_69, 10 October 2015 - 01:38.

exista in php vreo specificatie clara pentru ordinea in care este parcursa colectia pentru foreach si array_map?
in majoritatea limbajelor chestia asta e omisa, rezultatul fiind ca cele 3 bucati de cod din primul topic nu fac intotdeauna acelasi lucru (atunci cand operatia efectuata e ceva mai complicata decat simpla atribuire a unei valori)

_Smiley_, on 10 octombrie 2015 - 08:02, said:

Cand vorbesti despre array-uri in PHP, vorbesti despre mai multe lucruri care in alte limbaje au constructe diferite: hash table, list, tuple.

Pentru liste, ordinea e bine definita: dupa index.

Pentru hash table, ordinea e la fel ca in orice alt limbaj: aleatorie. Unele limbaje (ex. golang) merg intr-atat de departe incat chiar randomizeaza ordinea inainte de iterare.

Intr-un dictionar (hash table) nu te intereseaza ordinea, ci asocierea key => value.

Problema in PHP e ca poti trata un array cand ca lista, cand ca dictionar, si de multe ori nici nu iti dai seama ca ai trecut de la una la alta.

In PHP iti trebuie mai multa disciplina fata de alte limbaje, disciplina pe care nu o poti castiga daca nu ai programat intensiv in alte limbaje mai stricte (gen C/C++, Java, golang, rust).

maxtron_69, on 10 octombrie 2015 - 01:24, said:

Intr-o arhitectura layered, poti instantia strategia (obiectul functional) pe care urmeaza sa i-o pasezi lui array_map "din afara" sistemului. Cand i-o pasezi sistemului (caci faci dependency inversion), ea trece prin toate layerele intermediare, si fiecare layer o poate manipula - deoarece e un obiect.

Astfel, cand ajunge la array_map, ea e pregatita si adaptata la situatia de la runtime.

De exemplu, sa zicem ca aceasta strategie e una dintre "core values" ale business-ului, si ca ai diferiti clienti care platesc diferit pentru diferite facilitati (clienti basic, premium sau VIP).

Pastrezi software-ul la fel, doar ca injectezi strategia potrivita. Alt avantaj e ca ai aceste strategii la un loc, nu imprastiate prin tot codul, prin toate layerele, prin if-uri si else-uri care nu exprima idei cu business value. Adica te poti uita la trei clase in paralel si determina cu usurinta care sunt diferentele dintre cele trei tipuri de clienti. Adica unui nou membru din echipa de dezvoltare ii va fi mult mai usor sa creeze un nou tip de client: va implementa o noua clasa si o va pune langa cele 3 deja existente. Si uite asa ai din nou presiune cognitiva redusa, doar ca la un nivel de abstractizare mult mai ridicat (deci si impactul / beneficiile sunt mai mari).


La fel e si in Java si in mai orice alt limbaj practic, probabil d-aia nu a intrebat.

Edited by OriginalCopy, 10 October 2015 - 14:36.

OriginalCopy, dai meditatii? Ca vreau si eu
Nu stiu cu ce te ocupi, dar pare ca you know your shit.

Eu tot incerc sa citesc Design Patterns_ Elements of Reusable Object-Oriented Software si nu ma invrednicesc...

maxtron_69, on 10 octombrie 2015 - 13:43, said:

Da, dar costa. Nu bani.

OriginalCopy, on 10 octombrie 2015 - 14:40, said:

Dar ce costa? Sint interesat