marrtins

pārfrāzē savu pēdējo postu, patlaban tas izklausās pēc klajas snobiskas diršanas

Nu a kāds tad tika prasīts?

Man jau ar tā šķiet - neko negaidu, pasaku tik cik man tas izmaksā tādu uzbliezt.

250Ls + dizains.

Cik es esu testējis šos pdf2html pdf2txt tūļus - nekas prātīgs tur nenāk ārā... :/

Man gan liekas, ka tam /tmp ir 1777, t.i., sticky bits ir uzstādīts, kas nozīmē, ka tu vari čakarēt tikai tos failus, kas pieder Tev. Ierakstīt var visi, bet dzēst/mainīt/labot var tikai owners. Vai es kļūdos saistībā ar sticky bitu tiesībās?

nu veči, šis fōrums ar katru dienu spārda ar aizvien nevaldāmāku jaudu :D

vājprāts....

Tu par ko runāt? Sajūta, ka par mani, bet taču nē? Ja tomēr, tad varam padiskutēt... Un kāds vēl fukken reitings? Tu domā postu skaitu? Tad paskaties labāk uz tiem gudreļiem, kas tik izsmeļoši atbild visiem topikiem, `probleeeeema`, `a man neiet`, `a man paziņojums DB ERROR, ko darīt?`, `neprotu nekā, bet nesanāk` Roze, un tad? Pamanīju interesantu tēmu (kas šeit ir ļoooti maz) un ierakstīju. Kādas problēmas?

uid1 = 107871 OR uid2 = 107871 indexu nevar izmantot, jo 1) izmantot index uz tikai uid1 - nav jēgas, tāpat jāskanē vēl pēc uid2 2) izmantot index uz uid1 un uid2 kopā - nav jēgas, jo indeksā uid2 ir sakārtots pēc uid1 (ar AND starpā - uķipuķi smuki buci) 3) izmantot index uz tikai uid1 un index uz tikai uid2 kā atseviški indexi - MySQL prot izmantot tikai vienu indexu vienam selektam/joinam (iespējams, citās DBVS ir savādāk) Tas, ka šo pieprasīju vienkārši var pārvērst par union, iespējams, ir MySQL query optimiziera speciālgadījums (nepilnība?).

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

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.

Ideja tāpati, izpaliek tikai funkcijas izsaukums.

Iespējams, ka man nav gadījies tiešām lieli projekti, bet šādā tāda pieredze ir ;) Saraksts/mapings tiek veidots visiem PHP failiem, kas tiek inklūdēti vienalga ar require, include, require_once, include_once. stat() netiek kešots? Šī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. 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. :) 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.

Ir atšķirība starp `can` un `should` Tas pats vien ir. Tiem postiem parasti nepievēršu uzmanību - nekas interesants, kur varētu palīdzēt :) 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.

Jā, tas nu toč tad būs ātrāk - visa optimizācija aiziet ar str_replace + define + string concat :D

Dažas pārdomas. 1. If a method can be static, declare it static. Speed improvement is by a factor of 4. Statisks vai nestatisks ir jāizvēlas konkrētai problēmai, jādomā par progrmamas struktūru nevis par ātrdarbību. Ko vispār nozīmē `by a factor of 4.`? 2. echo is faster than print. Jā, bet ātrdarbības ieguvums ir niecīgs un web aplikāciju izstrādē faktiski ir nulle. 3. Use echo's multiple parameters instead of string concatenation. Tas pats, kas pie 2. 5. Unset your variables to free memory, especially large arrays. `especially large arrays` + objects es piekristu, pasvītrojot `especially large`. Tas ir noderīgi, ja skriptiem uzstādīts memory_limits, stipri apšaubu, ka šādi tiek atbrīvota sistēmas atmiņa, man prātā stāv, ka unset tikai atbrīvo skripta PHP atmiņu, lai vēlāk to izmantotu citiem datiem skripta kontekstā. 7. require_once() is expensive Ja? Liekas, ka tur ir tikai viena papildus pārbaude pirms inclūdot. 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. 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. 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. Tas pats, ka 4.? 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. 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. 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. Tas pats, kas pie 2. 33. bla bla bla... if (!isset($foo{5})) { echo "Foo is too short"; } ...bla bla bla... Nu nav tas ātrdarbības ieguvums tik ļoti liels, lai es šādi sačakarētu savu kodu - pēc 1/2gada pamēģini izlasīt, kas te ir domāts. 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

P.S. CGI/FastCGI man nav aktuāli (vismaz pagaidām)

Tas nozīmē, ka ar Turck bija neprātīgie apache segfaulti, kas turpinājās eaccelerator sākuma versijās (par pēdējām nezinu - kā jau teicu, tagat lietoju APC) Tiesa par tām PHP versijām - uz 4.x.x APC gļukoja uz vella paraušanu, bet tākā nu jau sen sēžu uz PHP5 - nekādu (redzamu/jūtamu) problēmu nav bijis.

Pēc manas pieredzas APC strādā daudz stabilāk par eaccelerator (lietoju vēl no Turck laikiem - pirms kāda gada pārgāju uz APC), kā arī eaccelerator baigi reti tiek izlaistas jauna versija. Man čota arī šķiet, ka kaut kas nav tīrs ar tiem testiem - serialize ātrāks nekā APC? :o

Memcache izmantot ir vērts, ja ir daudzi serveri, kam jākešo vieni dati - visi slēdzas pie memcached un ņemās. Serialize un faili - ļoti slikti (serialize/unserialize relatīvi LĒNS pasākums), kaut arī uz ramdiska, jo jāseko līdzi vai divi procesi nesāk rakstīt failā. Ja to var izkontrolēt - var mēģināt. MySQL heap - arī ideāls variants, lai glabātu kādus rezultātus savilktus kopā no citām tabulām. Šajā gadījumā ideāls variants man izskatās APC (http://www.php.net/apc) - izveidojam PHP masīvu un kašā iekšā - un nolasas arī kā jau PHP masīvu bez jebkādiem overhead kā būtu ar serialize.

60Ls par PSD salikšanu css+html vēl verētu, ja tas dizains ir pietiekami vienkāršs. Bet nejau kopā ar php, mysql, ajax :o

portfolio?

būs :) bet tutors baisi laps gan.

khe khe, nu nebūs jau nu gan tāpat kā C, jo if(defined()) nav tas pats kas macrosi iekš C/C++/Delphi utmldz *kompilējamām* valodām. ja tas mmcache tā dara (esmu gan pārliecināts, ka tā nav), tad tas būtu nežēlīgi *wrong* un ir konkrēts bugs. (mmcache gadienā nebi discontinued un to pārņēma citi kēxi zem nosaukuma eaccelerator ?). pēc Tevis teiktā sanāk, ka aiz if(!defined()) {} else {šite namz netiks izpildīts kods} :)) andrisp piedāvātais kods nedarbotos, ja inklūdē būs vnk pārbaude if(IS_INCLUDED), jo tad gan PHP izdomātu to pārveidot par stringu (jo nedefinēta konstante), kas, protams, automātiski ir true