- Argos: Szeretem az ecetfát
- gban: Ingyen kellene, de tegnapra
- Elektromos rásegítésű kerékpárok
- btz: Internet fejlesztés országosan!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- gerner1
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- hdanesz: Hyundai Ioniq 28kWh - Első benyomások - második felvonás
- sziku69: Szólánc.
Új hozzászólás Aktív témák
-
válasz
Tele von Zsinór #2863 üzenetére
Kipróbáltam a módszert, és érdekes módon úgyis gyorsabb, hogy először beolvasom az össze fájlt egy másik fáljba, majd azt adom a php-nak hogy értelmezze.
Érdekes, de nagyon.
-
válasz
Sk8erPeter #2862 üzenetére
Nem, csak az volt, hogy ciklusba voltak ágyazva az include-ok, kábé így:
while(iteráció) {
include('ugyanaz a fájl.');
}Én hülyeségem.
HTML űrlap generálás miatt kellett, s nem ilyen volt hanem sok egymásba ágyazott ciklus, így állandóan a winyón kellett kaparnia 17 fájl után, amiből néhányat akár 70x is be kellett ágyazni. Írtam egy osztályt, ami gyorsítótárazva ágyaz be, azaz ha valamit beágyaz, akkor beírja egy változóba is a benne lévő php scriptet, majd ha mégegyszer be kéne ágyazni, akkor már a memóriából olvassa be a scriptet, s eval-lal újra lefuttatja. Persze a szkript lefutása után törlődnek a cuccok a memóriából, így ezzel "csak" 5x tempót értem el, ami még mindig 2x lassabb az egy fájlos módszernél, úgyhogy fogtam magam és becache-eltem egy fájlba az egész generált űrlapot (ami 200x gyorsabb), oszt kész, az úgyis ritkán változik
class Cached_Include {
private static $_cache;
public static function inc($inc, &$importVars)
{
$inc = dirname(__FILE__) . '/' . $inc;
if(!self::$_cache[$file]) {
self::$_cache[$inc] = '?>' . file_get_contents($inc) . '<?';
}
extract($importVars, EXTR_REFS | EXTR_SKIP);
eval(self::$_cache[$inc]);
}
public static function save()
{
file_put_contents('cache.txt', serialize(self::$_cache));
}
public static function load()
{
self::$_cache = unserialize(file_get_contents('cache.txt'));
}
}Sebességek amúgy:
sok fájl, no optimalizálás: 1200-1500ms
sok fájl, cachelt include: 180-200ms
egy fájl (minden ebben van): 80-100ms
cachelve az egész hóbelevanc: 1-10ms -
Nagyon úgy néz ki, hogy az a 17 include 1 másodpercet vesz igénybe, amik Qrvára sok! Nyomok egy defragot, hátha segít...
Szerk:
Aha: 22.8kB adat 152 kB helyet foglal.
Szerk2:
egy másik szkriptem még több fájlt használ, de az nagyságrendekkel gyorsabb.
Viszont abban a fájlok osztályokat tartalmaznak, itt meg (nem echózott) HTML kódot, benne pár <?php echo $var ?> cuccal.Szerk3:
Ugyanolyan lassú hulladék töredezettség nékül is.
Ötlet?
-
válasz
Sk8erPeter #2850 üzenetére
pü
-
válasz
Sk8erPeter #2848 üzenetére
Hát én valami PHP könyvet ajánlanék, lehetőleg PHP5öst, pl a Tanuljuk meg 24 óra alatt a PHP-t az kezdésnek jó, beavat mindenbe ami kell a problémád megoldásához. Ha esetleg tudsz angolul, akkor meg neten találsz rengeteg e-book-ot pdf-ben. Dummies sorozatot ajánlom még nagyon - a stílusa miatt.
-
Sok kis fájlra szedtem egy több egymásba ágyazott ciklusból álló 300 soros űrlap-generáló szkriptet + átírtam az echo-kat a php tageken kívülre, s a szkriptem sebessége a tizedére csökkent.
Most vajon sok include miatt lassult be, és/vagy az echotalanítás miatt?
-
Tapasztalta valaki, hogy az Aptana képes gondolatolvasásra autokieg terén?
-
-
<?php
// fájlnevek
$in = 'bemenet.txt';
$out = 'bemenet.txt';
$temp = md5($out);
// fájlokat megnyit
$input = fopen($in, 'r');
$tmp = fopen($temp, 'w');
// iterál
$i = 1;
while(! feof($input)) {
// sort beolvas
$line = fgets($input);
// páratlan sort beír a kimenetbe
if($i % 2 == 1) {
fputs($tmp, $line);
}
$i++;
}
fclose($input);
fclose($tmp);
// ha létezik a kimeneti fájl már, akkor felülír
if(file_exists($out)) {
unlink($out);
}
// átnevez
rename($temp, $out); -
Gyorsabb, memóriakímélő pufferelős módszer:
<?php
// fájlnevek
$in = 'bemenet.txt';
$out = 'kimenet.txt';
// fájlokat megnyit
$input = fopen($in, 'r');
$output = fopen($out, 'w');
// iterál
$i = 1;
while(! feof($input)) {
// sort beolvas
$line = fgets($input);
// páratlan sort beír a kimenetbe
if($i % 2 == 1) {
fputs($output, $line);
}
$i++;
}
// fájlokat bezár
fclose($input);
fclose($output);Az eredmény ugyanaz, csak ez szinte semennyi memóriát se eszik és jóval gyorsabb.
-
<?php
// beolvas
$text = file_get_contents('bemenet.txt');
// sorokra darabol
$lines = explode(PHP_EOL, $text);
// iterál
for($i=0;$i<count($lines);$i++) {
// minden második sort töröl
if($i % 2 == 1) {
unset($lines[$i]);
}
}
// sorokat összefűz
$text = implode(PHP_EOL, $lines);
// fájlbaír
file_put_contents('kimenet.txt', $text);bemenet.txt és kimenet.txt fájlneveket cseréld arra, amire kell. A feldolgozandó fájlnak a szkript mellett kell lennie, illetve a kimenet is a szkript mellé kerül.
Annyit még hozzátennék, hogy kis fájlokra ideális, nagyobb (több megabájtos) fájlokra már igencsak lassúcska és zabálja a memóriát.
-
Én módszeremmel se megy?
Itt a teljes, működő script kód,
a félig átlátszóságot előre kell beállítani a png fájlban.$image = imagecreatefromjpeg($this->file);
$imageWidth = imagesx($image);
$imageHeight = imagesy($image);
$watermark = imagecreatefrompng("watermark.png");
$watermarkWidth = imagesx($watermark);
$watermarkHeight = imagesy($watermark);
imagealphablending($watermark, true);
imagecopy(
$image,
$watermark,
round(($imageWidth - $watermarkWidth) / 2), // vízszintesen középre
round(($imageHeight - $watermarkHeight) / 2), // függőlegesen középre
0,
0,
$watermarkWidth,
$watermarkHeight);
imagejpeg($image);A végén csak beállítod, hogy mentse a képet, ne pedig megjelenítse.
-
Húú, átlátszósággal én is rengeteg szívtam régen.
Működő honlapból szedtem ki ezt a feldolgozó-kódrészletet:
imagealphablending($watermark, true);
imagecopy(
$image, // a kép forrásobjektum
$watermark, // a vízjel forrásobjektum
round(($imageWidth - $watermarkWidth) / 2), // horizontálisan középre
round(($imageHeight - $watermarkHeight) / 2), // vertikálisan középre
0,
0,
$watermarkWidth,
$watermarkHeight);FONTOS!! A vízjel eleve legyen részben átlátszó.
-
válasz
Tele von Zsinór #2785 üzenetére
-
A mai nappal megérkezett a stabil PHP 5.3.0, egy rakás újítással:
- namespaces,
- late static binding,
- closures (anonim függvények),
- optional garbage collection for cyclic references,
- new extensions (like ext/phar, ext/intl and ext/fileinfo),
- over 140 bug fixes and much more.Migration Guide: [link]
-
válasz
ArchElf #2702 üzenetére
Hát erre a IIS+PHP4+MSSQL kombóra csak annyit tudok mondani, hogy jajjj...
Amúgy szerintem ezt a session_set_save_hander() függvényt csak akkor van értelme használni, ha már egy kész weblapnak akarod átalakítani a munkamenet-kezelését. Mert amúgy szerintem több értelme van egy teljesen új, független kezelőt írni, pl OOP-ben.
-
Javascript ügyében erősen ajánlom egy framework használatát (pl Prototype), hogy cross-browser legyen, gondolom emiatt nem működik az ajax.
Az időzítős dologra prototype-ban pl már van kész függvény: Ajax.PeriodicalUpdater
-
-
válasz
ArchElf #2669 üzenetére
Én a sima mezei Eclipse PDT-ből használom a 2.1 RC-t, 2 hét múlva fog kijönni a stable, autocomplete egész jó (PHPEclipse-nél messze jobb, nem értem miért nem a PDT-t használod, ha már eclipse
), a js support is nagyon jó, van autocomplete ott is (kb mint a JSEclipse, talán még jobb is), xml-kezelése majdnem mint egy Oxygen XML. Előtte volt még nuspere PHPed, phpDesigner, de azok nem jöttek be, ráadásul nem ingyen vannak.
Eclipse-szel nekem eddig csak egy bajom volt: FTP. De ez megoldható az ingyenes NetDrive-val - de x64 egyelőre nem támogatott, arra sajnos nincs ingyenes alternatíva.
-
válasz
fordfairlane #2587 üzenetére
Nekem már a FF blokkolta...
-
válasz
zhagyma #2556 üzenetére
Pont azért találták ki az OOP-t, hogy hatalmas nagy kódmennyiség mellett is átlátható legyen a program. OOP lényege, hogy egy helyre kerül az adat és annak feldolgozása.
Dehogy gyakorlati példát is mondjak: mysql_ függvények vs MySQLi classIlletve ott van a rengeteg OOP pattern: factory, adapter, singleton, stb.
-
válasz
zhagyma #2554 üzenetére
Egyetértek, plusz még fontos akkor szerintem az is beletartozik a dologba, hogy nyílt legyen új technológiák megtanulására.
Hát persze, a dokumentálás az alap.
Ha meg megfelelően van lebontva namespace-ekre az a pár ezer objektum, úgy azért nehezebb eltévedni köztük. Minden csak dokumentáció és a világos kód kérdése. -
Jah az más, de akkor sem értem még, miért nem használtál eddig OOP-t PHP-nál.
Egy ideig én is csináltam úgy pár honlapot, hogy kizárólag AJAX-szal történt minden, de aztán rájöttem, hogy a google nem tudja indexelni az oldalakat, hisz JS szükséges hogy elérd őket. Illetve a másik probléma az volt, hogy hát lassú, sok JS-kóddal kellett vesződnöm, huhh, nagy hülyeség volt.
Azután csináltam magamnak egy saját MVC Frameworkot (Orchid Frameworkből kiindulva, csipet Zend Framework segítségével, de 90% magamtól, folyamatosan fejlesztem, sose lesz kész
), amiben van egy jó kis Nézet renderer (nuku AJAX, csak ha nagyon kell, akkor), Controllerben minden egyes Nézet fájl-ra tudok beállítani helyi változókat (van kb 40), így kavarodás se nagyon van. Automata CSS és JS beágyazás a layout-ot felépítő minden egyes kis html fájlnál, így azokat se kell egybe ömleszteni, illetve kézzel beágyazni...
[...]
Sokat lehetne erről írni. Nézz utána, bőven van értelme, sokkal gyorsabban és könnyebben lehet vele összedobni egy weboldalt - még ha minimális szerepe is van benne az adatbázisnak, akkor is.
-
Hát ha eddig mindent OOP nélkül csináltál, akkor gratula.
Ha nekem OOP nélkül kellett volna csinálnom mindent eddig, akkor már megőszültem volna.Egyébként szerintem nagyon számít az OOP ismerete egy profi programozónál. Hisz anélkül nagyságrendekkel több időbe telik a fejlesztés - nem viccből találták ki. Meg ott van az MVC is. Illetve szerintem PHP-hoz nem ártanak alapos (My)SQL ismeretek sem.
De ez az én véleményem.
A legegyszerűbben úgy derül ki, hogy profi programozó vagy-e nekik, hogy elmész.
-
válasz
@Pirate@ #2540 üzenetére
Nekem megeszi a PHP a kódod. JS-t hanyagold, meg lehet kerülni, s akkor gebasz lesz.
EREG helyett meg szvsz használj PREG-et, sokkal kevesebb kóddal le lehet írni ugyanazt, meg többet is tud, illetve PHP 6.0-tól meg fog szűnni az EREG kiterjesztés.(#2537) ttower:
Nem tud több PHP-kód egyszerre futni? Ez biztos?Nekem ez új.
szerk: Mi a fene? Ha a vissza gombbal megyek vissza a szerkesztéshez, akkor lehet 5 perc után is szerkeszteni?(#2542) Cucka: Akkor lehet, hogy a az EREG kódja hibás.
-
válasz
Fire/SOUL/CD #2535 üzenetére
Nincs mit, szerintem nem fogok belehalni.
-
Ja, ööö, most nézem, hogy nálad a változókat beleírja meg minden, csak értéket nem ad. De nálam se működik a kód.
szerk: De mégse írtam hülyeséget az előző postomban, mert ha kicseréled a másik kódra akkor működik.
szerk2: Heh, közbe rájöttem, hogy ezt a függvényt a kód végén kell használni, nem előtte... Akkor ezek szerint nem egy meglévő működő kód php4 => php5 migrációról van szó.
Mindegy... Használd akkor a globális $_SESSION tömböt, ne a régi függvényeket.
-
válasz
Fire/SOUL/CD #2531 üzenetére
Lehet, hogy ki van kapcsolva a session_register függvény. Így a session változók a $_SESSION nevű asszociatív tömbben vannak. Alapból egyébként már a PHP 5.3-ban lesz/van kikapcsolva, PHP 6.0-val pedig már megszűnik a függvény.
Így kéne átírni:
$_SESSION["proba_nev"] = "Nem_megy";
$_SESSION["proba_jelszo"] = "de_miert_nem";De ha nagyon sok mindent kéne átírnod (sokszor használod a változókat), akkor szerintem ezt csináld, s akkor így csak a session_register-eket kell átírni:
$proba_nev = &$_SESSION["proba_nev"];
$proba_jelszo = &$_SESSION["proba_jelszo"];
$proba_nev = "Nem_megy";
$proba_jelszo = "de_miert_nem";szerk.:
Utóbbi esetben szerintem eressz rá minden fájlra egy PREG-et - ha támogatja a szerkesztőprogid, s akkor gyorsan megvagy:keresés (regular expression):
'/session_register\("(.*?)"\)/'csere:
'\$$1 = &\$_SESSION["$1"]' -
-
Najó, akkor kénytelen vagyok írni egy saját Parser-t. A hibaüzeneteket meg hibakódok alapján azonosítom.
Valaki tud valami jó PHP-szerkesztőt? Jelenleg phpDesigner2008-cal dologozom, de az XML-hez nem igazán konyít, gondolok itt pl XSL és XSD tagnév-kiegészítésekre. Dreamweaver az egész kellemesnek mondató ebből a szempontból, de az meg a php-hoz síkhülye.
-
Sziasztok!
Szükségem lenne valami XML Schema kezelő php-s cucc-ra, mert a php5 beépített DOM-ja csak validálást tud, s pl a hibaüzeneteket (amiket a libxml-ből kell külön előkotorni) is legfeljebb csak PREG-gel lehetne értelmezni, nincs semmi kedvem erre külön programot írni. Szóval az a kérdés, hogy tud valaki valamilyen nagyobb tudású XML Schema kezelő library-t vagy extension-t?
mod: Ami pl a node-okat objektumokba rendezné, stb, hogy egyszerűen kitudjak nyerni belőle adatokat, pl arra, hogy form-ot csináljak belőle, stb.
-
válasz
Tele von Zsinór #1901 üzenetére
A szerkesztőprogi (phpDesigner 2008) a php-t használja CGI-n keresztül (syntax ellenőrzés, debug), és nekem nem sikerült az apache-ra a PHP-t CGI-ként tenni, úgyhogy hagytam a fenébe letöröltem mindent és felnyomtam egy XAMPP-ot, amiben minden benne van, és instant megy.
-
L3zl13, Tele von Zsinór:
Sajnos nem megy semmilyen módszerrel sem.
XAMPP-ot használok, mert csak az hajlandó együttműködni php-szerkesztőmmel.
Lehet hogy annak a konfigurációjával van gond? -
Sziasztok!
Az lehetséges hogy a php header() függvénye CGI módban, csak korlátozottan használható?
Az tudom, hogy a getallheaders() meg pár függvény nem működik CGI-ben. A gyakorlati probléma az, hogy nemtudok 404 státuszkódot csinálni, az oldal úgy csinál mintha ott se lenne rá az utasítás. De a Location-os átírányítás pl müxik.
Új hozzászólás Aktív témák
Hirdetés
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Renault, Dacia topik
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- PlayStation 5
- Azonnali fotós kérdések órája
- exHWSW - Értünk mindenhez IS
- Melyik tápegységet vegyem?
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Samsung Galaxy A56 - megbízható középszerűség
- Argos: Szeretem az ecetfát
- További aktív témák...
- HP core i5-ös fémházas Folio 9470m kifogástalan állapotban!! AkciÓÓ!
- A legolcsóbb!!! Dell Latitude 6. gen. core i5-ös notebook olcsón!!!! AkciÓÓ!
- Olcsó Laptop! Dell Latitude 7280. I5 7300U / 8GB DDR4 / 256GB SSD
- MSI Thin GF63 12VF 15.6" FHD IPS 5-12450H RTX 4060 16GB 512GB NVMe magyar vbill gar
- Apple iPhone 16 Pro Max - Desert Titanium - 256GB 1 ciklus 100% akku! 1 év garancia! Új készülék!
- AKCIÓ! ASUS B650M R5 7600X 64GB DDR5 1TB SSD RTX 3080Ti 12GB Be Quiet! Pure Base 500FX ASUS 1000W
- BESZÁMÍTÁS! MSI SUPRIM X RTX 4080 16GB videokártya garanciával hibátlan működéssel
- Lenovo Legion Slim 5 82Y900BVHV Notebook
- ÖRÖK GARANCIÁVAL - OLCSÓ, LEGÁLIS SZOFTVEREK 0-24 KÉZBESÍTÉSSEL - Windows - Office - LicencAruhaz.hu
- AKCIÓ! AMD Ryzen 9 3900X 12 mag 24 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest