Kód-optimalizálás php-ban
Kód v5 – szövegkezelés kicsit másképp
Az XDebug bekapcsolása és a profil kiértékelése közben kiderült, hogy a szövegmanipuláló függvények nagyon sokszor futnak le. Ez nem is csoda, hiszen ezekkel állítjuk elő a mindenkori variációs string-et, amit utána a gyorsított megoldásunkkal összehasonlítunk. Jó lenne ezeken megint faragni egyet.
Támadott kód
$pos = strrpos($variation, (string)$lrn); if ($pos !== false) { $actual_variation = substr($variation, 0, $pos + 1) . "," . $rn . substr($variation, $pos + 1, strlen($variation)); $inserted = true; break; } |
Amit itt csinálunk, az a 2 és 3 fős szobák értékének helyreillesztése, hogy ne kelljen a rendezéssel törődni, hanem eleve rendezett variációt állítsunk elő. Amitől biztosan nem tudunk szabadulni, az a pozíció meghatározása, mivel tudnunk kell, hova illesszük be az új értéket. Amin viszont változtatni tudunk, az a beillesztés módja.
Jelenleg az iskolás módszert használjuk, ahol a beillesztési pont előtti és után szövegrészt levágjuk, majd közöttük az új elemmel összefűzzük őket.
Egy – nem éppen erre szánt – beépített függvény megfelelő paraméterezésével azonban nyerhetünk egy “szúrj be a szövegbe egy új darabot a megadott helyre” függvényt. Ez pedig a substr_replace()
.
Eredeti szándék szerint szövegdarabok kicserélésére szolgál, viszont a cserélendő szövegrész hosszának elfogadja a 0 értéket is, ami annyit jelent, hogy a megadott pozíciótól számított 0 karaktert vegye ki, és a helyére tegyen be másikat.
Kiváltó kód
$pos = strrpos($variation, (string)$lrn); if ($pos !== false) { $actual_variation = substr_replace($variation, "," . $rn, $pos + 1, 0); break; } |
Igazából itt már tényleg csak töredék-ezred-másodpercekről beszélhetünk, de a teljesség igénye miatt, a verzió erőforrásigénye:
A memóriahasználatot mutató grafikonon azért csak a 4-es verzió görbéje látszik, mivel a két változatban teljesen megegyezik a memóriahasználat, különbség csak a futási sebességben jelentkezik (ez is csak 28-20 fő számításától kezdve)
KCachegrind profil a módosítás után:
(A profiler futtatásakor böngészőn keresztül hívtam meg a kódot, 50 vendégre)
Szöveges értelmezésben:
- 1 másodpercen belül kiszámítható: 97 fő
- 30 másodpercen belül kiszámítható: ? fő (megáll memórialimit miatt)
- 25 fő érkező vendég kiszámítása: 0.005 másodperc
- 128MB memórialimit elérése: 121 vendég számításánál
Értékelés: szakértői munka.
Eddig csak a sebességre koncentráltunk, cserébe beáldozva az elérhető memóriamennyiséget. A kódunk így a sportos futásért cserébe igencsak éhes lett. Jó hír viszont, hogy a sebesség megtartása mellett is rábírhatjuk egy kis “fogyókúrára”…
MySQL jogosultság-szervezés MAC-alapú kivétel Mikrotik hotspot-ba
Comments are currently closed.