Pagina 1 din 1

optimizare cod php

Scris: Sâm Ian 19, 2008 1:46 am
de mandriva2007
uite de ex eu am creat un script simplu care extrage datele din doua tabele si face un join dupa care le baga in a treia .dar pt asta sta de iti vine rau.alt script si mai simplu care it ifacea un count dupa useri care bagau ceva un tabel sa zicem un numar.si de ex pt acelasi user imi aprea cate numere a bagat el si stea deaprca rula o mie de lini de program.asta pe postgres instalt pe linux red hat enteprise.dar ceva nue in regula.am citi si chestia ia ca un script php are alocat pe default 8 M pt rulare.ma iales ca fac vacuum in fiecare zi pe tabele.mihaita ridica problema rapiditatii.desi sunt pe la inceput am obervat si eu ca ca o sesiune cu if si else e mult mai rapida.ar fi bine dak cineva a facut teste pe diferite versiuni de php.de ex citema acum pe web aceste chestii: 1. If a method can be static, declare it static. Speed improvement is by a factor of 4.
2. echo is faster than print.
3. Use echo's multiple parameters instead of string concatenation.
4. Set the maxvalue for your for-loops before and not in the loop.
5. Unset your variables to free memory, especially large arrays.
6. Avoid magic like __get, __set, __autoload
7. require_once() is expensive
8. Use full paths in includes and requires, less time spent on resolving the OS paths.
9. If you need to find out the time when the script started executing, $_SERVER[’REQUEST_TIME’] is preferred to time()
10. See if you can use strncasecmp, strpbrk and stripos instead of regex
11. str_replace is faster than preg_replace, but strtr is faster than str_replace by a factor of 4
12. If the function, such as string replacement function, accepts both arrays and single characters as arguments, and if your argument list is not too long, consider writing a few redundant replacement statements, passing one character at a time, instead of one line of code that accepts arrays as search and replace arguments.
13. It's better to use select statements than multi if, else if, statements.
14. Error suppression with @ is very slow.
15. Turn on apache's mod_deflate
16. Close your database connections when you're done with them
17. $row[’id’] is 7 times faster than $row[id]
18. Error messages are expensive
19. Do not use functions inside of for loop, such as for ($x=0; $x < count($array); $x) The count() function gets called each time.
20. Incrementing a local variable in a method is the fastest. Nearly the same as calling a local variable in a function.
21. Incrementing a global variable is 2 times slow than a local var.
22. Incrementing an object property (eg. $this->prop++) is 3 times slower than a local variable.
23. Incrementing an undefined local variable is 9-10 times slower than a pre-initialized one.
24. Just declaring a global variable without using it in a function also slows things down (by about the same amount as incrementing a local var). PHP probably does a check to see if the global exists.
25. Method invocation appears to be independent of the number of methods defined in the class because I added 10 more methods to the test class (before and after the test method) with no change in performance.
26. Methods in derived classes run faster than ones defined in the base class.
27. A function call with one parameter and an empty function body takes about the same time as doing 7-8 $localvar++ operations. A similar method call is of course about 15 $localvar++ operations.
28. Surrounding your string by ' instead of " will make things interpret a little faster since php looks for variables inside "..." but not inside '...'. Of course you can only do this when you don't need to have variables in the string.
29. When echoing strings it's faster to separate them by comma instead of dot. Note: This only works with echo, which is a function that can take several strings as arguments.
30. A PHP script will be served at least 2-10 times slower than a static HTML page by Apache. Try to use more static HTML pages and fewer scripts.
31. Your PHP scripts are recompiled every time unless the scripts are cached. Install a PHP caching product to typically increase performance by 25-100% by removing compile times.
32. Cache as much as possible. Use memcached - memcached is a high-performance memory object caching system intended to speed up dynamic web applications by alleviating database load. OP code caches are useful so that your script does not have to be compiled on every request
33. When working with strings and you need to check that the string is either of a certain length you'd understandably would want to use the strlen() function. This function is pretty quick since it's operation does not perform any calculation but merely return the already known length of a string available in the zval structure (internal C struct used to store variables in PHP). However because strlen() is a function it is still somewhat slow because the function call requires several operations such as lowercase & hashtable lookup followed by the execution of said function. In some instance you can improve the speed of your code by using an isset() trick.

Ex.
if (strlen($foo) < 5) { echo "Foo is too short"; }
vs.
if (!isset($foo{5})) { echo "Foo is too short"; }

Calling isset() happens to be faster then strlen() because unlike strlen(), isset() is a language construct and not a function meaning that it's execution does not require function lookups and lowercase. This means you have virtually no overhead on top of the actual code that determines the string's length.
34. When incrementing or decrementing the value of the variable $i++ happens to be a tad slower then ++$i. This is something PHP specific and does not apply to other languages, so don't go modifying your C or Java code thinking it'll suddenly become faster, it won't. ++$i happens to be faster in PHP because instead of 4 opcodes used for $i++ you only need 3. Post incrementation actually causes in the creation of a temporary var that is then incremented. While pre-incrementation increases the original value directly. This is one of the optimization that opcode optimized like Zend's PHP optimizer. It is a still a good idea to keep in mind since not all opcode optimizers perform this optimization and there are plenty of ISPs and servers running without an opcode optimizer.
35. Not everything has to be OOP, often it is too much overhead, each method and object call consumes a lot of memory.
36. Do not implement every data structure as a class, arrays are useful, too
37. Don't split methods too much, think, which code you will really re-use
38. You can always split the code of a method later, when needed
39. Make use of the countless predefined functions
40. If you have very time consuming functions in your code, consider writing them as C extensions
41. Profile your code. A profiler shows you, which parts of your code consumes how many time. The Xdebug debugger already contains a profiler. Profiling shows you the bottlenecks in overview
42. mod_gzip which is available as an Apache module compresses your data on the fly and can reduce the data to transfer up to 80%

in detaliu gasiti la pagina asta: http://reinholdweber.com/?p=3

Scris: Sâm Ian 19, 2008 4:10 am
de saitek
Chestiaaaa asta a fost pusa de muuuuuuuuuult pe web blog la phpromania...

Scris: Sâm Ian 19, 2008 8:51 am
de Quber
da mandriva2007 acuma a observat ;)

da acum am am obesrvat

Scris: Dum Ian 20, 2008 2:40 pm
de mandriva2007
se mai intampla,de obicei citesc problmele ridicate si care mi se mai par ma interesante,ai al ui mihaita a fost parca la tinta.dar nelamurirle mele erau altele.de ce se misca ata de greu php ???dak fac iacela si program in c si lpui pe linux se misca mai repede .am incercat .e o observatie .folosesc un sistem red hat entreprise si se observa.in fine poate pe anumite versiuni de php se misca ma irepede .asta eu nu pot sa o afirm pt ca nu am incercat ,dar cred ca exista pe forum care au testat acest lucru.oricum f interesant ce a postat mihaita .apropo o carte de ansembler sa un forum de ansambler m-ar interesa .multumesc anticipat

Interesant

Scris: Mar Ian 22, 2008 8:50 am
de andreivig
Am mai dat si eu peste cateva din regulile de mai sus dar cea de la punctul 8 mi se pare eronata.

E mult mai costisitor sa folosesti tot timpul FULL PATH in functii gen require sau include .. cel putin pe sistemele LINUX.

De exemplu daca ai o structura arborescenta cu 6 nivele se vor face tot timpul 6 cautari in tabelele de inode-uri ale directoarelor .. pe cand daca folosesti RELATIVE PATH in cel mai rau caz apare acest scenariu.

Dar poate sa gresesc si daca cineva stie motivul pt care fullpath e mai ok va rog sa postati.

Scris: Mar Ian 22, 2008 10:16 am
de mihaitha
E foarte simplu: iti lipsesc niste cunostinte de sisteme de operare, mai exact modul de adresare a fisierelor si folder-elor. Voi elabora:

faptul ca tu ai document_root in /var/site1/www/httpdocs sa zicem, si intr-un fisier php din root ai linia include('includes/fisier_inclus.inc'); nu usureaza deloc munca sistemului de operare. De ce? Pentru ca el nu are de unde sti in ce folder este fisierul respectiv. La rulare, fisierul este copiat in memorie si executat/interpretat de acolo. In momentul in care tu apelezi include(), munca grea cade pe interpretorul PHP (il voi numi in continuare I.P.) si pe sistemul de operare (S.O.). Anume:

1. I.P. ii spune sistemului de operare 'zi-mi in ce folder se afla fisierul pe care il rulez'.
2. S.O. se uita la informatiile fisierului si afla locatia copiei de pe disc.
3. S.O. cauta in FAT si in DT (directory table) in ce folder final se afla fisierul
4. S.O. aplica un algoritm recursiv (in ce folder se afla folder-ul acesta?) pana cand se ajunge la / (root dir) si astfel s-a obtinut calea completa a fisierului.
5. S.O. ii spune lui I.P. 'fisierul asta se afla in folderul /var/site1/www/httpdocs/
6. I.P. adauga la path-ul dat de S.O. argumentul functiei include(), rezultand /var/site1/www/httpdocs/includes/fisier_inclus.inc
7. I.P. spune sistemului de operare 'vreau sa interpretez fisierul asta'
8. S.O. cauta locatia fisierului in FAT si DT, il copiaza in memorie si ii spune I.P. 'l-am copiat la adresa asta...'
9. I.P. interpreteaza fisierul.

Buuun. Acuma sa vedem ce se intampla daca apelam include('/var/site1/www/httpdocs/includes/fisier_inclus.inc'):

1. I.P. spune sistemului de operare 'vreau sa interpretez fisierul asta'
2. S.O. cauta locatia fisierului in FAT si DT, il copiaza in memorie si ii spune I.P. 'l-am copiat la adresa asta...'
3. I.P. interpreteaza fisierul.

Observi diferenta?

Scris: Mar Ian 22, 2008 11:22 am
de andreivig
E foarte simplu: iti lipsesc niste cunostinte de sisteme de operare, mai exact modul de adresare a fisierelor si folder-elor.


nu stiu daca e chiar ok sa te pripesti in afirmatii.. cunosc in detaliu modul de adresare al fisierelor pe sistemele unix.

Eu ma refeream la ce ai descris tu la pasul 4 pt caile relative .. acel algoritm este mult mai costisitor in cazul FULLPATH decat in cazul RELATIVEPATH

P.S. pasul 3 e inclus in pasul 4

Scris: Mar Ian 22, 2008 12:59 pm
de mihaitha
andreivig scrie:nu stiu daca e chiar ok sa te pripesti in afirmatii.. cunosc in detaliu modul de adresare al fisierelor pe sistemele unix.

no shit???. Din ce zici si din incapatanarea cu care te cramponezi pe ideea ta, fara nici cea mai vaga urma de argumentare, tind sa cred ca nu m-am pripit.

andreivig scrie:Eu ma refeream la ce ai descris tu la pasul 4 pt caile relative .. acel algoritm este mult mai costisitor in cazul FULLPATH decat in cazul RELATIVEPATH

P.S. pasul 3 e inclus in pasul 4
Din nou... no shit???

Scris: Mar Ian 22, 2008 4:15 pm
de andreivig
Pentru a accesa un fişier din directorul curent, sistemul de operare citeşte fiecare intrare din directorul respectiv şi compară numele fişierului cu numele intrării, până când fişierul este găsit. Dacă fişierul este prezent, sistemul extrage din intrarea din director numărul de i-node şi îl foloseşte ca index în lista (tabela) i-node-urilor de pe disc, pentru a localiza structura asociată fişierului şi a o aduce în memorie. În i-node se găsesc toate informaţiile asociate fişierului, inclusiv adresele blocurilor alocate fişierului, deci prin
i-node-ul unui fişier sistemul are acces la datele fişierului. I-node-ul este citit de pe HDD şi încărcat în tabela i-node-urilor din memorie, care conţine toate i-node-urile fişierelor deschise. Tabela este gestionată intern de sistemul de operare.



Localizarea unui fişier care nu e situat în directorul curent este un lucru puţin mai dificil. De exemplu, pentru calea absolută /home/student/fis sistemul încarcă iniţial directorul rădăcină, al cărei i-node este cunoscut, fiind stabilit la formatarea partiţiei – de obicei i-node-ul cu numărul 2. După aceasta, caută printre intrările directorului rădăcină cea cu numele home şi găseşte i-node-ul asociat ei. I-node-ul este adus în memorie şi se determină blocurile de pe disc care conţin directorul /home. Intrările acestui director sunt citite şi comparate cu şirul student. O dată găsită intrarea, se extrage i-node-ul pentru directorul /home/student şi se citesc de pe disc blocurile sale de date. În final, se caută şirul fis printre intrările directorului /home/student şi se determină i-node-ul corespunzător fişierului fis şi, implicit, blocurile sale de date.


În general, utilizarea căilor relative poate fi mai convenabilă nu numai pentru utilizator, dar şi pentru sistem, pentru a se reduce numărul operaţiile de căutare şi accesurile la HDD.




Textul de mai sus este luat din cartea

Sisteme de operare scrisa de Iosif Ignat

Scris: Mar Ian 22, 2008 4:30 pm
de mihaitha
1. Si cu ce ma incalzeste asta? Directorul curent al php-ului este acela de unde ruleaza executabilul sau. Nu de alta, dar nu se duce apache cu cd, cd, cd... si sa apeleze ca pe un executabil php-ul respectiv. Toate fisierele sunt apelate absolut de apache (ai avut curiozitatea sa te uiti intr-un httpd.conf?).

2. Faptul ca S.O. cunoaste inode-ul fisierului nu inseamna ca stie si in ce folder se afla si toata structura arborelui pana la el.

3. Cat timp discutam aici de cod PHP pentru site-uri, nu pentru aplicatii CLI, las-o balta ca vorbesti pe langa.

4. In primul rand, aceste sfaturi au fost scrise de oameni cu mai multa experienta decat tine. In al doilea rand, nu zice nicaieri ca iti da cineva in cap daca nu le urmezi.

Scris: Mar Ian 22, 2008 8:07 pm
de carco
@andreivig, nu stiu sigur (mi-e cam lene sa caut prin sursele php-ului) dar banuiesc ca include "x/y.z" va fi translatat de interpretor-ul php in /path/to/x/y.z (adica la sistemul de operare sa ajunga tot calea absoluta).

Scris: Mie Ian 23, 2008 12:00 am
de andreivig
@mihaitha

doar din curiozitate .. imi explici te rog ce treaba are apache-ul (si mai ales httpd.conf-ul) cu includerea fisierelor intr-un script php?

Indiferent ca e o aplicatie cli sau e o aplicatie web sistemul de adresare al fisierelor e acelasi.

Test

Scris: Mie Ian 23, 2008 12:59 am
de andreivig
Pt a testa care modalitate de includere a fisierelor este mai buna am scris urmatorul script.

<?php

$start = microtime();

include 'cale/spre/fisier.php';

$stop = microtime();

var_dump($stop - $start);

?>

iar rezultatele au fost urmatoarele :

float(0.00034499999999998) cale/spre/fisier.php <=> fisier.php (fisierul era in directorul scriptului)

float(0.00087999999999999) cale/spre/fisier.php <=> var/www/html/test/fisier.php (fisierul era in directorul scriptului)

float(0.00059599999999999) cale/spre/fisier.php <=> /fisier.php (fisierul era in root)

Stiu ca testul poate parea rudimentar dar e cat de cat logic.

Oricum o sa urmez si ideea sugerata de carco si o sa parcurg si sursele php pt functiile include/include_once/require/require_once.

mda

Scris: Vin Ian 25, 2008 11:38 pm
de mandriva2007
am facut si eu testul acesta chiar cu un script si dak de exemplu scriptul php e in acelasi director cu scriptul din include se acceseaza mai rapid
de ex:
<?php
include("test.php");
?>
si acum chestiaai cu full path e prea mult de scris ,dar am so incerc si pe aia.
oricum in ce-a postat mihaita subiectul acela deschis de el era o treba f interesant ai cu if ,echo .acum m-ar interesa dak exista si alte artificii de genu lacesta pt imbunatirea timpului de executie a scriptului.sau poate zend creatorul a facut imbunatatiri pt viteza de compilare.