40 padomi kā optimizēt PHP kodu

[marrtins]

Tas jau tieši tu rakstīts - "if a method can be static". Ja konkrētā problēma pieļauj statisku metodi!.

"by a factor of 4" tulkojās kā četras reizes.

Ir atšķirība starp `can` un `should`

 

Manuprāt 4-tajā domāts kautkas šāds for ($x=0; $x<$y; $x++) { .... if ($something) { $y =10; } ... }

Tas pats vien ir.

 

Neesi pamanījis, cik daudz pat šī foruma apmeklētāju lieto neinicializētus mainīgos? :)

Tiem postiem parasti nepievēršu uzmanību - nekas interesants, kur varētu palīdzēt :)

 

Un visas tās sīkās lietas saucas par mikro optimizācijām. Varbūt katra atsevišķi neko daudz neietekmē, taču tad, kad projekts ir liels un tiek novērota liela bremze, tad vajag pameklēt vainīgo vietu. Varbūt tas ir neliels cikls, kura iekšienē pielietojot dažas no šīm lietām var panākt vajadzīgo ātruma pieaugumu. Kā jau v3rb0 saka - 20/80 likums.

Es to saprotu, tikai baidos, ka liels vairums tagat sāks kodēt stipri piedomājot pie katras rindiņas, kur likt echo, kur print vai izmantot single quotes vai double, likt ++ priekšā vai pakaļā, nočakarējoties daudz vairāk nekā tas ātrdarbības ieguvums. Pirmkārt jādomā par programmas uzbūvi, SQL vaicājumiem, cachingu, uttmldz - lietas, kuras optimizējot 0.0001% ātrdarbības pieauguma vietā var dot N-tās reizes ātrāku programmu.

[Roze]

Dažas pārdomas.

Izskatās ka neesi saskāries ar lieliem projektiem un ātrdarbības problēmām ;)

 

Nepārkomentēšu visu, bet tos kuri tiešām sāp..

 

7. require_once() is expensive

Ja? Liekas, ka tur ir tikai viena papildus pārbaude pirms inclūdot.

Uz 4.x šī ir ļoti "dārga" (salīdzinoši) funkcija attiecībā uz ātrdarbību.. Pārbaudes var būt ātras gan lēnas, konkrētajā gadijumā php jātur saraksts/mapings ar includētajiem failiem utt..

Uz 5.2.x jau ir krietni labāk un konkrētais punkts varbūt vairs nav tik aktuāls.

 

 

8.Use full paths in includes and requires, less time spent on resolving the OS paths.

WTF? Gribat, lai es hardkodēju visas inclūdes?? Apšaubu, ka iegūtā "ātrdarbība" ir tā vērta.

100% patiesi.. Uz relatīviem failiem PHP jaizpildi papildus stat() operācijas uz failistēmu un tas ir laikietilpīgi. Ļoti labi to var redzēt un padebugot ar strace.

 

 

16. Close your database connections when you're done with them

`when you're done with them` == `kad skripts beidz darbu`. Nekad nav gadījies vajadzība taisīt db_close kaukur pa vidu - lai PHP pats aizver visas figņas pēc skripta darbības beigām.

Ja runājam konkrēti par MySQL tad katra konekcija ir diezgan resursprasīga. Formula pēc kuras aprēķina MySQL patērēto atmiņu = key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections

Tas nozīmē ka katra lieka vaļēja konekcija lieki aizņem sortēšanas buferi (kas parasti ir ap 1Mb) un read buferi.. Un tad padomājam ja mums ir 100-1000 idlējošas konekcijas (teiksim php kaut ko citu dara ilgāk 2-3) uz DB serveri 1Gb rama ir wasted..

Ir gan ķēpīgi to darīt pašā php pusē.. Es to risinu ar mazu wait_timeout uz paša DB servera.

 

 

 

23. Incrementing an undefined local variable is 9-10 times slower than a pre-initialized one.

Vispār tizls stils kautko darīt ar neinicializētiem mainīgajiem.

Spožums un posts.. PHP ir zināmā mērā jauks un viss nav jādefinē :)

 

 

 

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.

Tikai vajadzības gadījumā patērētais laiks, lai pārvērstu ' par ", ir krietni lielāks, nekā ātrdarbības ieguvums.

Kad rodas vajadzība pārvērst ' par " ?

 

 

 

34. When incrementing or decrementing the value of the variable $i++ happens to be a tad slower then ++$i....

Vesels(!!!!) opcods :D :D :D nu i vērts pieminēt pie optimizācijas. Šādu konstrukciju (++$i) ir vērts izmantot kam tā ir paredzēta, nejau katrā vietā lai tikai ietaupītu vienu opcodu :D

Ja tu nesaprati tad minētie ieteikumi ir samērā zema līmeņa (ņemot vērā valodas īpatnības).. Par vispārīgām optimizāciju tur nekas daudz nav rakstīts un tas jālasa citur :)

[bubu]

Bet, ja metode var but statiska, labak nav vinu definet ka parastu funkciju...?

Pašlaik php vienīgais veids kā emulēt neimspeisus ir lietot statiskas metodes klasēs (ja vien neskaita patizlu veidu likt visām funkcijām prefiksus/sufiksus).

 

Tas pats vien ir.

Funkciju no mainīgā neatšķir?

[marrtins]

Izskatās ka neesi saskāries ar lieliem projektiem un ātrdarbības problēmām ;)

Iespējams, ka man nav gadījies tiešām lieli projekti, bet šādā tāda pieredze ir ;)

 

Uz 4.x šī ir ļoti "dārga" (salīdzinoši) funkcija attiecībā uz ātrdarbību.. Pārbaudes var būt ātras gan lēnas, konkrētajā gadijumā php jātur saraksts/mapings ar includētajiem failiem utt..

Uz 5.2.x jau ir krietni labāk un konkrētais punkts varbūt vairs nav tik aktuāls.

Saraksts/mapings tiek veidots visiem PHP failiem, kas tiek inklūdēti vienalga ar require, include, require_once, include_once.

 

100% patiesi.. Uz relatīviem failiem PHP jaizpildi papildus stat() operācijas uz failistēmu un tas ir laikietilpīgi. Ļoti labi to var redzēt un padebugot ar strace.

stat() netiek kešots?

 

Ja runājam konkrēti par MySQL tad katra konekcija ir diezgan resursprasīga. Formula pēc kuras aprēķina MySQL patērēto atmiņu = key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections

Tas nozīmē ka katra lieka vaļēja konekcija lieki aizņem sortēšanas buferi (kas parasti ir ap 1Mb) un read buferi.. Un tad padomājam ja mums ir 100-1000 idlējošas konekcijas (teiksim php kaut ko citu dara ilgāk 2-3) uz DB serveri 1Gb rama ir wasted..

Ir gan ķēpīgi to darīt pašā php pusē.. Es to risinu ar mazu wait_timeout uz paša DB servera.

Šīs formulas ir pazīstamas, taču piemērs ir speciālgadījums. Šajā gadījumā konkrētā vietā pieveram konnektu (ja zinam, ka turpmāk skripts ar DB nekomunincēs, bet pārējo laiku veltīs apstrādei), bet parastos "mirstīgos" :D skriptus darbinam kā ierasts.

 

Kad rodas vajadzība pārvērst ' par " ?

print 'I has eats your breinz.';

print "I has eats $some_var breinz.";

Konvertējot ' atpakaļ uz " tiek patērēts vairāk laika, nekā iegūtā ātrdarbība. :)

 

Ja tu nesaprati tad minētie ieteikumi ir samērā zema līmeņa (ņemot vērā valodas īpatnības).. Par vispārīgām optimizāciju tur nekas daudz nav rakstīts un tas jālasa citur :)

To es sapratu ;) cenšos vērst uzmanību, lai šis saraksts netiek pārprasts un tā optimizācija nepārvēršas par darbu kavēšanu - bāzt visās vietās šāda tipa optimizācijas un speciāli piedomājot, ka ++$c ir ātrāk par $c++ vai labot double quotes uz single, ir tikai darba efektivitātes samazināšanās bez redzama ieguvuma.

[marrtins]

Funkciju no mainīgā neatšķir?

Ideja tāpati, izpaliek tikai funkcijas izsaukums.

[Roze]

print 'I has eats your breinz.';

print "I has eats $some_var breinz.";

Konvertējot ' atpakaļ uz " tiek patērēts vairāk laika, nekā iegūtā ātrdarbība. :)

Ai nu.. programmētājs vienreiz izlabo patērējot 5min un tiek ieekonomēts CPU stundas uz ļimons requestiem .. :)

 

Aiz kam nekas nav jākonvertē:

echo 'Eat some '.$cookies.' for a change';

 

 

stat() netiek kešots?

Kurā galā lai viņš keshotos? Vienīgā iespēja ir likt kāda acceleratoru (piem eA) un pateikt viņam lai ignorē mtime pārbaudi, taču tad pēc katras izmaiņas php failos manuāli jatīra keš..

[marrtins]

Kurā galā lai viņš keshotos? Vienīgā iespēja ir likt kāda acceleratoru (piem eA) un pateikt viņam lai ignorē mtime pārbaudi, taču tad pēc katras izmaiņas php failos manuāli jatīra keš..

Domāju, ka OS līmenī - neesu pētījis kernel sources šajā sakarā, bet esmu visnotaļ pārliecināts, ka te ir kešings.

[marrtins]

Izveicu nelielu testu

include()

include_once()

require()

require_once()

 

lstat64() izsaukumu skaits visos gadījumos ir vienāds. Ja grib optimizēt, faktiski sanāk, ka vislabāk sources grūzt rootā /, jo pie katra direktoriju līmeņa ir viens lstat64()

 

P.S.

Testēts uz PHP5.2.4

[Delfins]

root-ā gluži nē, bet pietiks apakš-direktorijās. (lib,tmp,css,img,share,etc)

[Kaitnieks]

Njā, katram programmētājam jau laikam jāiziet cauri tai fāzei, kad visu gribās optimizēt, bet ja izmisums ir tik liels, ka x++ tiek mainīti pret ++x, tad varbūt ir vērts padomāt, vai nav kaut kādi kompleksāki uzlabojumi jāveic vai pat jāmaina izstrādes vide konkrētajam projektam. Katrā ziņā ir nācies sadarboties ar cilvēkiem, kas uzraksta murgainu kodu, pamatojot to ar optimizāciju ("es nedalu kodu funkcijās, jo tas ir lēnāk izpildē"), bet beigās tāpat izrādās, ka bottleneki ir citur un visa "optimizācija" ir pilnīgi bezjēdzīga, tikai sabojā koda kvalitāti.

Man patīk kaut kur sagrābstītie optimizācijas likumi:

Profesionāļiem: Neoptimizē.

Ekspertiem: Neoptimizē (pagaidām).

[Delfins]

Pēc tava teiktā - google, ebay un t.t. var uztaisīt vienā dienā... nekādu problēmu... :) Tikai vot tavs projekts būs tik labs, kā minētie.. nu esmu par 1000% pārliecināts, ka nē.

 

Tieši profi un experti raksta hardcode.. es nerunāju par PHP tikai.

Nūbi parasti raksta pļekainu kodu, mēģinot to optimizēt un kaut ko samuģīt.

 

Bet jāatceras, ka konkrētai videi ir savi likumi un iespējas,. Un pats galvenais - atkarīgs no paša projekta, vai ir paredzēts laiks optimizēšanai.

[Kaitnieks]

Pēc tava teiktā - google, ebay un t.t. var uztaisīt vienā dienā... nekādu problēmu... :) Tikai vot tavs projekts būs tik labs, kā minētie.. nu esmu par 1000% pārliecināts, ka nē.

 

Neesmu taisījis ne google, ne ebay apjoma projektus un man ir aizdomas, ka tuvākajā laikā arī netaisīšu. Tieši tāpat kā lielākā daļa Latvijas php programmētāju.

 

Bet jāatceras, ka konkrētai videi ir savi likumi un iespējas,. Un pats galvenais - atkarīgs no paša projekta, vai ir paredzēts laiks optimizēšanai.

 

Lūk šim es pilnībā piekrītu. Un tas attiecas arī uz iepriekš minētajiem google un ebay apjoma projektiem - tur iet runa par pavisam citiem likumiem un tur optimizācijai ir nozīme. Bet arī tur (ja izvēlētos php par izstrādes vidi) intensīvākas funkcijas, kurās tam pašam x++ un ++x ir nozīme, būtu svētīgi pārnest uz kompilētiem moduļiem.

 

Tagad, kad esmu actually izlasījis rakstu, ko mēs te apspriežam, piezīmēšu, ka īpaši atbalstu 41. punktu. Tam vajadzēja būt 1. Parasti sistēma bremzē ne jau dēļ pāris liekiem opkodiem, bet gan dēļ neefektīviem querijiem, ko savukārt izraisa nelāgi izveidota datu bāze, vai arī kaut kādas lietas tiek darītas dubultā, pa liekam, bremzē sliktu algoritmu izvēle utt - kur tas notiek, iespējams noskaidrot tikai profilējot. Es gribu uzsvērt, ka nevajag tos padomus njemt priekšā burtiski - "man ir lēna sistēma, ko darīt? o, pārtaisīšu visus " par ', objektus par masīviem un strlen par isset($s{}) un kods trauksies kaa veejsh" - vajag atrast neefektīvās vietas un novērst tās.

[Paulinjsh]

pietiek ar projektu ar 10k unikālajiem lietotājiem dienā, lai saprastu, ko nozīmē, ka viss sāk vilkties un jāoptimizē..

[andrisp]

Starpcitu, pamācošs raksts par to, ko vajag un ko nevajag optimizēt: http://datubazes.wordpress.com/2007/11/06/kur-paliek-laiks/