[PHP] Recursie mondt uit op een Segmentation fault

[LauPro]

Voor een soort van zoekmachine heb ik een systeem gemaakt op basis van een recursieve functie. De zoekmachine download een webpagina, vervolgens worden de links geparserd en die links gevolgd.

Nu is het zo dat wanneer ik bijvoorbeeld een forumwebsite door loopt dat een functie tot 4000+ zichzelf aanroept. Rond de 4000 krijg ik een dan een segfault. Nu heb ik een begrenzer gemaakt zodat hij bij '1000'-recursie-diepte 'stopt' en opnieuw begint, of eerst openstaand werk af maak.

Even wat speudo-code:

PHP:

function recursief($url) {
  $s = file_get_contents($url);
  $a = parseurls($s);
  foreach($a as $u) {
    if ($u not in $urldatabase) {
      recursief($u);
    } 
  }
}

Nu begreep ik dat het beter is om zo laag mogelijk te blijven qua recursie. PHP zou een zogenaamde stack gebruiken en als je daar teveel functies binnen aan roept loopt de zaak vast (segfault). Aangezien dit al snel om een batch gaat die langer dan een dag loopt is het natuurlijk de vraag of php wel de geschikte taal is, nu ben ik er wel achter gekomen dat het downloaden meer tijd kost dan het parsen, dus op zich valt het wel mee.

Maar wat kan nu precies die segfault veroorzaken en hoe kan ik hem voorkomen?

[Grijze Vos]

Een stack overflow zou best een segfault kunnen veroorzaken. Overigens, -elke- omgeving gebruikt een stack voor functie-aanroepen. Waar anders wil je de doorgegeven variabelen op kwijt?

[LauPro]

Mja dat zou kunnen, maar ik heb het geheugengebruik voor php al op 256 MB gezet, dus dat lijkt me voldoende? Zeker voor een 'diepte' van 4000. Nu hij een tijdje loopt zit hij op 15% mem usage, dat zou neerkomen op zo'n 90 MB. Dat is best fors overigens imo.

[Glimi]

Als je ipv een Depth First Search nou een Breadth First Search dmv een queue zou doen, dan zal je recursiediepte geen probleem meer zijn. BFS is gewoon het parsen van een pagina in je queue en vervolgens alle gevonden pagina's toevoegen aan de queue.

[edit] DFS is trouwens ook goed te doen als je gewoon zelf je stack vult en dus niet de call naar je functie in je functie zelf doet. dus:

code:

Stack s = new Stack();
s.push( base_url );

while( !s.empty() )
do 
  url = get_content( s.pop );
  links = parselinks( url );
  foreach( links as link )
  do
    s.push( link );
  end foreach
end while

Dan is ie trouwens wel van rechts naar links werkend, maar dat is ook simpel aan te passen.

[ Voor 51% gewijzigd door Glimi op 19-05-2005 14:54 ]

[igmar]

LauPro schreef op donderdag 19 mei 2005 @ 14:09:
Nu begreep ik dat het beter is om zo laag mogelijk te blijven qua recursie. PHP zou een zogenaamde stack gebruiken en als je daar teveel functies binnen aan roept loopt de zaak vast (segfault). Aangezien dit al snel om een batch gaat die langer dan een dag loopt is het natuurlijk de vraag of php wel de geschikte taal is, nu ben ik er wel achter gekomen dat het downloaden meer tijd kost dan het parsen, dus op zich valt het wel mee.

Maar wat kan nu precies die segfault veroorzaken en hoe kan ik hem voorkomen?

Omdat PHP voor elke functie ook een C functie aanroep, en die ze de waarden van alle registers op de stack. Aangezien de stack een beperkte grootte heeft kun je dus ook maar een beperkt aantal functies recursief aanroepen. Een functie > 4000 keer recursief aanroepen is als je het mij vraagt een probleem met je ontwerp.

[LauPro]

Ontwerp, ontwerp, ik ben gewoon even wat aan het proberen uit de losse pols . Ik kan me voorstellen dat zo'n stack over loopt maar toch vind ik het raar. Met BFS gebruik je dus meer geheugen, alleen dan geheugen buiten de stack waardoor je in principe de zaken aan het verdelen bent. En waarschijnlijk zal in dit geval het geheugengebruik (> 2 GB) zo groot worden dat ik het dan naar wat disks moet gooien al snel. Een grotere stack zou imo dan een betere oplossing zijn, is die stack niet te vergroten?

[__fred__]

Een recursief algoritme kun je eigenlijk altijd omschrijven naar een iteratieve versie. Dit is een behoorlijke standaardvaardigheid voor een programmeur, vooral om bovengenoemde reden: de stackgrootte is beperkt.

Dit zijn misschien links die je op weg helpen:

Removing recursion:
http://user.it.uu.se/~lms...ingar/recursion-appl.html

goed boek over algoritmen:
http://www.cs.ioc.ee/yik/lib/4/Sedgewick1.html

Edit: geloof dat de eerste link al een 404 is, terwijl ik hem aan het tikken ben. nou ja.

[ Voor 11% gewijzigd door __fred__ op 19-05-2005 14:56 ]

[Glimi]

LauPro schreef op donderdag 19 mei 2005 @ 14:49:
Ontwerp, ontwerp, ik ben gewoon even wat aan het proberen uit de losse pols . Ik kan me voorstellen dat zo'n stack over loopt maar toch vind ik het raar. Met BFS gebruik je dus meer geheugen, alleen dan geheugen buiten de stack waardoor je in principe de zaken aan het verdelen bent. En waarschijnlijk zal in dit geval het geheugengebruik (> 2 GB) zo groot worden dat ik het dan naar wat disks moet gooien al snel. Een grotere stack zou imo dan een betere oplossing zijn, is die stack niet te vergroten?

Ho ho ho, BFS zal alleen meer gebruiken als je boom breed is (wat ik me wel kan voorstellen met urls op een pagina) echter een DFS dmv een stack zal zeker minder geheugen gebruiken dan een recursieve DFS, omdat een recursieve functie eerst helemaal naar beneden gaat voordat hij wat begint op te ruimen.

[LauPro]

Ik wilde _juist_ voorkomen dat het een scriptje werd dat enkele honderden MB's in het geheugen aan gaat roepen, vandaar de recursieve functie. Maar blijkbaar is het er niet op gemaakt dus zal ik het idd gewoon met een 'simpele' queue zonder recursie doen. Het probleem is wel dat je voor een website als Tweakers.net als je het snel wil houden al snel over een machine praat met 6 GB ram oid (wil je bijvoorbeeld Tweakers.net kunnen indexeren, uitgaande dat t.net uit 1 miljoen unieke links bestaat (met Got dan welliswaar).

[Kuhlie]

Die Stack of Queue of wat dan ook hoeft natuurlijk niet in het geheugen te blijven staan. Je kunt best een deel, of zelfs alles, in een database zetten... wees creatief

[bigbeng]

Eerste linkje van __fred__ (aka de prutser ) moet zijn:
http://user.it.uu.se/~alm...7/Anteckningar/index.html

En ja, ik had niks beters te doen

[LauPro]

Kuhlie schreef op donderdag 19 mei 2005 @ 18:30:
Die Stack of Queue of wat dan ook hoeft natuurlijk niet in het geheugen te blijven staan. Je kunt best een deel, of zelfs alles, in een database zetten... wees creatief

Dat snap ik, maar een database van 6 GB op disk doorspitten op of de url als langs is gekomen is nogal tijdrovend, dit via het geheugen doen is velen malen sneller. Maar ik ben nu al bezig om voor een kleine versie de zaak gewoon tijdelijk in een db of een file te mikken, op zich wel aardig.

[Gomez12]

En als je nou gewoon 100 url's in memory gooit, worden het meer dan fifo naar dbase. Een script wat langer dan een dag bezig is geheel in het geheugen laten draaien is trouwens leuk als je een crash hebt, al het werk van een dag kwijt

[LauPro]

De systemen die ik gebruik zijn over het algemeen uiterst stabiel. Ik heb nog nooit zomaar een segfault gehad die totaal onverklaarbaar was. Dus het lijkt me stug dat iets *zomaar* crasht. Een hardwareprobleem is mogelijk, maar het nu wel zo dat er tussentijds zodra er iets gevonden is dat naar een database toe gaat. Ik heb nu het script ruim 70 minuten lopen, hij heeft bijna 80.000 links geïndexeerd, waarvan er nu ruim 20.000 in de database staan. Dat betekent zat hij nog ruim 75% in het geheugen (16 MB overigens nu totaal) staat dat nog moet worden afgehandeld. Op zich een leuke score, maar ik vrees dat de snelheid erg omlaag gaat als de zaak direct naar wat disks gaat, zal het wel even benchmarken. Uiteraard zou er natuurlijk ook een bug in het script kunnen zitten, maar die heb je er naar verloop van tijd wel uit denk ik.

[ACM]

Ik heb vaker meegemaakt dat php in dergelijke gevallen segfaulte, dus je hebt inderdaad een slecht afgeschermde limitatie van php geraakt.

Blijkbaar is er in nieuwere php-versies rekening mee gehouden:

PHP:

<?

        function recursion($i = '')
        {
                recursion($i++);
        }

        recursion(0);
?>

Fatal error: Maximum function nesting level of '100' reached, aborting! in /home/acm/temp/recurse.php on line 5

Dus mocht je php 4.3.11 willen gebruiken, dan werkt je bovenstaande code sowieso al niet meer. Die limiet van 100 is overigens bijzonder klein in mijn ogen...

[LauPro]

Nu gebruik ik PHP 5.0.3 (cli). Als je eenmaal kennis hebt gemaakt met PHP5 WIL je geen PHP4 meer . Maar daarin zit die beveiliging zo te zien niet. Misschien moet ik instellen in de php.ini.

[Verwijderd]

LauPro schreef op vrijdag 20 mei 2005 @ 10:23:
Nu gebruik ik PHP 5.0.3 (cli). Als je eenmaal kennis hebt gemaakt met PHP5 WIL je geen PHP4 meer . Maar daarin zit die beveiliging zo te zien niet. Misschien moet ik instellen in de php.ini.

Probeer dan voor de gein ook eens een echte OO taal, java ofzo .

OT: Je zou zelf je het maximaal aantal recursive calls kunnen voorkomen door een $level mee te geven aan de functie. De functie roept dan de volgende functie aan met $level + 1. Indien $level > 100 return; je gewoon ofzo.

[LauPro]

Ik werk ook vrij veel in Java (al). Maar ik moet helaas zeggen dat ik nog niet gecharmeerd ben van de snelheid, alleen de NetBeans IDE bijvoorbeeld is bij mij niet vooruit te branden met de Sun JRE 1.4.2.08 (Linux 2.6.10-gentoo-r6, AMD XP 64 3000+/768 MB Ram, Raptor etc; aan het systeem ligt het niet imo).

Nu snap ik wel dat PHP totaal iets anders is dan Java, maar ik heb toch een vrij groot vermoeden dat in deze gevallen PHP een stuk sneller en hanteerbaarder is. Uiteindelijk zal ik denk ik naar een native C++ app gaan. Maar inmiddels heb ik de functie herschreven zodat er geen recursie meer plaats vind, en hij draait al enkele uren foutloos dus dat gaat prima.

Maar om even terug te komen om dat PHP4/5 verhaal. PHP5 heeft imo dermate grote wijzigingen (met name qua objecten e.d.) in petto dat het imo onverstandig is om nu nog alle software in PHP4 te maken. Je zal hoe dan ook binnen een jaar toch een keer over moeten gaan wil je alles een beetje up to date houden. Ik hou er zelf niet van om tot in de treuren toe oude versies te ondersteunen, en volgens mij zijn er vrij weinig native PHP3-sites meer. De overgang van PHP3 naar PHP4 was ook vrij ingrijpend.

[ Voor 7% gewijzigd door LauPro op 21-05-2005 02:34 ]

[ACM]

Verwijderd schreef op zaterdag 21 mei 2005 @ 01:04:
Probeer dan voor de gein ook eens een echte OO taal, java ofzo .

Sja, in Java krijg je inderdaad een Error, geen segfault... Niet dat je daar nou zo enorm veel mee kan, want met je data uit je functies kan je op dat moment niks meer, tenzij je die Error probeert te catchen en dat wordt over het algemeen bij Error's bijzonder sterk afgeraden.

LauPro schreef op zaterdag 21 mei 2005 @ 02:33:
Ik werk ook vrij veel in Java (al). Maar ik moet helaas zeggen dat ik nog niet gecharmeerd ben van de snelheid, alleen de NetBeans IDE bijvoorbeeld is bij mij niet vooruit te branden met de Sun JRE 1.4.2.08 (Linux 2.6.10-gentoo-r6, AMD XP 64 3000+/768 MB Ram, Raptor etc; aan het systeem ligt het niet imo).

Dat is een klassieke fout die mensen over Java maken. De performance aflezen a.d.h.v. een complexe Java-applicatie die compleet anders is dan hetgeen je zelf nodig hebt. Bovendien is NetBeans geloof ik niet bepaald een toonbeeld van de mogelijke performance in Java. Ik neem tenminste maar aan dat jij geen GUI, continue input-analyzing (voor de syntax highlighting en auto completion enzo) en al dat soort zaken nodig hebt in jouw applicatie...

Nu snap ik wel dat PHP totaal iets anders is dan Java, maar ik heb toch een vrij groot vermoeden dat in deze gevallen PHP een stuk sneller en hanteerbaarder is. Uiteindelijk zal ik denk ik naar een native C++ app gaan. Maar inmiddels heb ik de functie herschreven zodat er geen recursie meer plaats vind, en hij draait al enkele uren foutloos dus dat gaat prima.

Java is helemaal niet trager dan PHP en PHP is niet trager dan Java. Het hangt vooral van wat je doet en hoe je dat gedaan hebt af hoe snel het is. Bij Java heb je bijvoorbeeld het voordeel dat je meerdere threads tegelijk url's kan laten fetchen en de resulterende data in een queue kan laten zetten om te verwerken door weer een andere thread (provider/consumer idee).

Maar om even terug te komen om dat PHP4/5 verhaal. PHP5 heeft imo dermate grote wijzigingen (met name qua objecten e.d.) in petto dat het imo onverstandig is om nu nog alle software in PHP4 te maken. Je zal hoe dan ook binnen een jaar toch een keer over moeten gaan wil je alles een beetje up to date houden. Ik hou er zelf niet van om tot in de treuren toe oude versies te ondersteunen, en volgens mij zijn er vrij weinig native PHP3-sites meer. De overgang van PHP3 naar PHP4 was ook vrij ingrijpend.

Volgens mij was het verschil tussen 3 en 4 vooral onderhuids en was 4 (grotendeels) backwards compatible met 3. Er werd kwa zichtbare wijzigingen vooral nieuwe functionaliteit toegevoegd, voor zover ik me het nog herinner.
PHP5 is daarentegen met OO niet (geheel) backwards compatible met 4, o.a. door die grapjes met de &'s die nu niet meer nodig zijn (of mogen?) en de wijziging in de manier hoe objecten meegestuurd worden aan functies.

[LauPro]

ACM schreef op zaterdag 21 mei 2005 @ 11:13:
Dat is een klassieke fout die mensen over Java maken. De performance aflezen a.d.h.v. een complexe Java-applicatie die compleet anders is dan hetgeen je zelf nodig hebt. Bovendien is NetBeans geloof ik niet bepaald een toonbeeld van de mogelijke performance in Java. Ik neem tenminste maar aan dat jij geen GUI, continue input-analyzing (voor de syntax highlighting en auto completion enzo) en al dat soort zaken nodig hebt in jouw applicatie...

Dat mag dan wel zo zijn, alleen als ik kijk naar bijvoorbeeld KDevelop en die open trek dan is dat binnen 3 seconden. NetBeans doet er zeker een halve minuut over. KDevelop kent voor zover ik zie meer of danwel evenveel functies. Dat is toch een groot verschil imo. Misschien dat NetBeans een betere OO structuur heeft, maar daar heb ik niet zoveel aan, ik wil snel en productief werken. Dat je applicatie 30 seconden duurt om om te starten is imo pre-1995. jEdit duurt ruim 8 seconden (Kate binnen 1 seconde) en de de Eclipse IDE zit bij de 20. Zo kan ik nog wel even door gaan. Naar mijn idee is Java gewoon niet de juiste taal in deze. Als ik de zaak sneller wil ga ik wel naar native C++ dan heb ik ook threads e.d..

Java is helemaal niet trager dan PHP en PHP is niet trager dan Java. Het hangt vooral van wat je doet en hoe je dat gedaan hebt af hoe snel het is. Bij Java heb je bijvoorbeeld het voordeel dat je meerdere threads tegelijk url's kan laten fetchen en de resulterende data in een queue kan laten zetten om te verwerken door weer een andere thread (provider/consumer idee).

Dat zal in de praktijk misschien zo zijn, echter de IDE's waar ik mee heb gewerkt voor Java die 'voelen' gewoon niet goed aan in snelheid, het is gewoon telkens wachten en wachten. Een beetje het idee dat ik had bij een P1 100 Mhz met Visual Basic 5. Moet ik dan een dual Opteron workstation aanschaffen om goed met Java te kunnen werken? Begrijp me niet verkeerd, ik werk veel met Java echter vind ik dat die performance vooral bij wat complexere structuren nog gewoon onder de maat is. Waarschijnlijk is dat over 5 jaar opgelost maar daar heb ik nu niets aan.

Volgens mij was het verschil tussen 3 en 4 vooral onderhuids en was 4 (grotendeels) backwards compatible met 3. Er werd kwa zichtbare wijzigingen vooral nieuwe functionaliteit toegevoegd, voor zover ik me het nog herinner.
PHP5 is daarentegen met OO niet (geheel) backwards compatible met 4, o.a. door die grapjes met de &'s die nu niet meer nodig zijn (of mogen?) en de wijziging in de manier hoe objecten meegestuurd worden aan functies.

PHP4 was niet OO, PHP5 gaat de goede richting ermee op. Dat is denk ik de beste beschrijving. Maar denk met name aan het declareren van vars in klassen dat nu middels private, protected of public moet. Dat zijn toch wel een aantal ingrijpende code-wijzigingen. Overigens zijn er ook flink wat ingrijpende wijzigingen geweest bij PHP3 <> PHP4, de eerste google hit: http://www.alt-php-faq.org/local/1/ . Je zult maar net 100+ klassen op die mannier hebben ingedeeld, dan kan je dat straks allemaal gaan aanpassen.

[B-Man]

Java traag? Voor de applicaties die ik draai zeer zeker niet. Ik draai ook een heel stel 24/7 applicaties die veel data verwerken, en heb daar 4 jaar geleden (toen ik begon met de ontwikkeling van een stel ervan) voor java gekozen.
- PHP was (en is) in mijn ogen niet klaar voor 24/7 draaien. Ja, wel de ad-hoc manier van scripts op een website, maar niet voor losse scripts die je als 'server' draait.
- Java is zeer snel in de '-server' mode, als de JIT compiler een tijdje zijn werk heeft kunnen doen. Het verschil met C++ (ik heb het eens getest) viel zwaar tegen, zelfs op het gebied van string handling (wat traag is/was in java), werden snelheidsverschillen in de orde van milliseconden pas zichtbaar bij meer dan 10.000 iteraties van complexe lussen in mijn applicatie.

Ter info: dit alles draait op reguliere intel bakken: P4 2,4 GHz, 1GB ram, simpele ATA IDE schijfjes.

Ik werk veel met zowel PHP als Java (en doe ook geregeld dingen in C++), en vind beiden talen heerlijk om mee te werken. Maar kort door de bocht: ik zou PHP dus niet inzetten voor 'applicaties' die los van apache draaien (afgezien van shell scripts).

[ACM]

LauPro schreef op zaterdag 21 mei 2005 @ 13:53:
Dat mag dan wel zo zijn, alleen als ik kijk naar bijvoorbeeld KDevelop en die open trek dan is dat binnen 3 seconden. NetBeans doet er zeker een halve minuut over. KDevelop kent voor zover ik zie meer of danwel evenveel functies. Dat is toch een groot verschil imo. Misschien dat NetBeans een betere OO structuur heeft, maar daar heb ik niet zoveel aan, ik wil snel en productief werken.

En dat is het tweede slechte voorbeeld, door de VM zal java per definitie wat trager starten dan C/C++-applicaties, php ook trouwens... Als jouw enige argument om Java niet te gebruiken de IDE is, kijk dan naar IDEA. En ja, dat start ook traag (15 secs hier oid)... Maar voelt verder snel (genoeg) aan.

Dat je applicatie 30 seconden duurt om om te starten is imo pre-1995. jEdit duurt ruim 8 seconden (Kate binnen 1 seconde) en de de Eclipse IDE zit bij de 20. Zo kan ik nog wel even door gaan. Naar mijn idee is Java gewoon niet de juiste taal in deze. Als ik de zaak sneller wil ga ik wel naar native C++ dan heb ik ook threads e.d..

Ik snap nog steeds niet waarom je Java afdoet als "niet de juiste taal", onder de argumentatie dat er trage IDE's zijn. Jouw applicatie heeft toch nog steeds geen GUI nodig? Jouw applicatie wordt toch niet tientallen keren per seconde opnieuw opgestart?
Dat je Java niet wilt gebruiken is helemaal je eigen keuze, maar je argumentatie vind ik zo raar
Heeft KDevelop trouwens naast syntax highlighting nog meer geavanceerde taal features? On the fly analysis voor fouten en gevaarlijke of onhandige constructies? Code completion inclusief functie en variabelenamen en dat soort zaken?
Want dat zijn nou net de zaken waardoor sommige Java IDE's wat traag aanvoelen. Afgezien van gewoon slecht programmeerwerk natuurlijk.

Dat zal in de praktijk misschien zo zijn, echter de IDE's waar ik mee heb gewerkt voor Java die 'voelen' gewoon niet goed aan in snelheid, het is gewoon telkens wachten en wachten. Een beetje het idee dat ik had bij een P1 100 Mhz met Visual Basic 5. Moet ik dan een dual Opteron workstation aanschaffen om goed met Java te kunnen werken? Begrijp me niet verkeerd, ik werk veel met Java echter vind ik dat die performance vooral bij wat complexere structuren nog gewoon onder de maat is. Waarschijnlijk is dat over 5 jaar opgelost maar daar heb ik nu niets aan.

Door de OO en JVM overheads kan Java op sommige punten nog wel wat trager zijn dan C++, maar ik ben er vooralsnog van overtuigd dat Java helemaal niet zo ongeschikt is als jij het nu doet voorkomen.

PHP4 was niet OO, PHP5 gaat de goede richting ermee op. Dat is denk ik de beste beschrijving. Maar denk met name aan het declareren van vars in klassen dat nu middels private, protected of public moet. Dat zijn toch wel een aantal ingrijpende code-wijzigingen.

Ik ken de verschillen van 4 vs 5 redelijk goed en heb vanmiddag nog even teruggezocht naar de verschillen tussen 3 vs 4. PHP4 heeft ondersteuning voor klassen en objecten en je zou dat OB kunnen noemen. Met PHP5 is die ondersteuning behoorlijk uitgebreid inderdaad.

Overigens zijn er ook flink wat ingrijpende wijzigingen geweest bij PHP3 <> PHP4 geweest, de eerste google hit: http://www.alt-php-faq.org/local/1/ . Je zult maar net 100+ klassen op die mannier hebben ingedeeld, dan kan je dat straks allemaal gaan aanpassen.

Maar dat is dan wel zo'n beetje de meest ingrijpende wijziging die ik gezien had, dat je initializers statisch moeten zijn ipv dynamisch zoals bij php3 mocht. Overigens is deze beperking inderdaad wel vrij sneu, want je mag zelfs niet var $bla = 1 + 2; ofzo opgeven, wat net als de concat in de preprocessor of parser al allemaal uitgewerkt kan worden.

Dat je niet meer met &'s kan werken en die dus allemaal uit je code moet verwijderen vind ik aanzienlijk ingrijpender.

[LauPro]

ACM schreef op zaterdag 21 mei 2005 @ 14:38:
En dat is het tweede slechte voorbeeld, door de VM zal java per definitie wat trager starten dan C/C++-applicaties, php ook trouwens... Als jouw enige argument om Java niet te gebruiken de IDE is, kijk dan naar IDEA. En ja, dat start ook traag (15 secs hier oid)... Maar voelt verder snel (genoeg) aan.

Ik zal eens kijken naar IDEA. Momenteel heb ik nog niet zoveel ervaring met Java op server gebied, dat moet ik toegeven. Ik zal dit ook nog even gaan uitzoeken om een volledig beeld te krijgen. Alleen als ik nu al merk dat een C++/QT applicatie qua GUI soms nog sneller is dan een ncurses-'frontend'. Vraag ik me af waar die traagheid vandaan komt bij de Java GUI. Ik kan me niet voorstellen dat het afhandelen van een GUI dermate veel resources vereist dat de zaal zo erg vertraagd wordt.

Ik snap nog steeds niet waarom je Java afdoet als "niet de juiste taal", onder de argumentatie dat er trage IDE's zijn. Jouw applicatie heeft toch nog steeds geen GUI nodig? Jouw applicatie wordt toch niet tientallen keren per seconde opnieuw opgestart?
Dat je Java niet wilt gebruiken is helemaal je eigen keuze, maar je argumentatie vind ik zo raar

Wat ik probeer aan te geven: als een 'simpele' IDE al zo traag wordt in java, hoe kan een geavanceerd systeem met enkele tientalle modules en enkele tientalle MB's aan code dan nog snel werken in Java? PHP kan dit momenteel voor zoveer ik weet, maar met Java durf ik het gewoon niet aan nog. Maar ook speelt een klein stukje onweten, ik zal dit uit gaan zoeken.

Heeft KDevelop trouwens naast syntax highlighting nog meer geavanceerde taal features? On the fly analysis voor fouten en gevaarlijke of onhandige constructies? Code completion inclusief functie en variabelenamen en dat soort zaken?
Want dat zijn nou net de zaken waardoor sommige Java IDE's wat traag aanvoelen. Afgezien van gewoon slecht programmeerwerk natuurlijk.

KDevelop heeft syntax highlighting, auto-complete er zijn plugins beschikbaar waarmee je fouten in talen kan ontdekken (is nog beta moet ik toegeven), er zijn debugggingsmogelijkheden, echter momenteel alleen voor PHP3 - maar dat is meer omdat er nog geen fatsoenlijke debugger is voor PHP5 geloof ik. Iig, kijk hier maar eens naar: http://www.kdevelop.org/i...ilename=3.0/features.html . Je kan er dus ook C++ mee ontwikkelen en je kan er ook Java mee ontwikkelen, hetzij beperkt. In het totaal zijn er een tiental talen native ondersteund en daarbij nog heel veel andere (script) talen waarbij het gewoon als 'editor' fungeert met een aantal functies.

Door de OO en JVM overheads kan Java op sommige punten nog wel wat trager zijn dan C++, maar ik ben er vooralsnog van overtuigd dat Java helemaal niet zo ongeschikt is als jij het nu doet voorkomen.

Kijk, dat Java iets trager is als je de cijfertjes gaat vergelijken met een native C++ app vind ik niet zo erg, dat is PHP of een .NET applicatie ook. Maar het gaat er om dat wanneer iets significant 'traag' is (dus 30+ seconden om op te starten) dat mijn vertrouwen dan wat geschaad wordt. Dan kan je wel zeggen van 'dat is niet de juiste vergelijking'. Maar wat is er precies dan traag? Alleen de GUI? Java is dacht ik in eerste instantie ontworpen voor een goede GUI op allemaal platformen, raar dat dit dan juist het traagste punt zou zijn.

Maar dat is dan wel zo'n beetje de meest ingrijpende wijziging die ik gezien had, dat je initializers statisch moeten zijn ipv dynamisch zoals bij php3 mocht. Overigens is deze beperking inderdaad wel vrij sneu, want je mag zelfs niet var $bla = 1 + 2; ofzo opgeven, wat net als de concat in de preprocessor of parser al allemaal uitgewerkt kan worden.

Mja hoe dan ook, ik geef even aan dat er toen ook vrij veel mensen 'tegen' PHP4 waren omdat ze hun code moesten veranderen, dat zie je nu ook met PHP5. Uiteindelijk is iedereen toch over gegaan op PHP4. Dus je kan nu wel blij gaan roepen dat PHP5 'niets' is, maar uiteindelijk ben je toch aan de beurt.

Dat je niet meer met &'s kan werken en die dus allemaal uit je code moet verwijderen vind ik aanzienlijk ingrijpender.

Dat je niet meer met &'s kan werken is dan nieuw voor mij, ik gebruik ze nog volop. Zou je een voorbeeld kunnen geven?

@B-Man: PHP van 4 jaar geleden idd niet klaar om 24/7 te draaien. Tegenwoordig met PHP5 (ja ga ik weer ) wordt je code geoptimaliseerd en een gecompileerd door PHP. Het is niet meer zo dat bij elke request het script opnieuw geparsed wordt e.d., dat haalt hij allemaal uit het geheugen. En er zijn zelfs dingen als MMCache voor PHP4 om dat te versnellen, en het verschil is merkbaar, zeker bij grote stukken. Ik heb zelf een verbetering van ruim 30% in de gemiddelde parse-time gezien toen ik Inkoopacties.net van PHP4 naar PHP5 om zetten, daarbij heb ik dus ook vrij veel dingen geoptimaliseerd qua objecten die in PHP4 niet konden.

Het probleem bij PHP is echter dat er standaard geen goed platform wordt meegeleverd om je code goed in te delen, bij Java zijn deze voorzieningen er standaard. Maar als je eenmaal in PHP zelf zo'n platform hebt gemaakt dan kan kan je zeker de concurrentie met Java aan.

Maar nogmaals voor de duidelijkheid: ik heb diversie dingen in Java gemaakt en ik ben momenteel ook met een vrij grote Applicatie weer bezig. Ik ben geen tegenstander van Java alleen ik denk dat het nog wel even duurt voordat alle Java applicaties ook zelf zo lekker snel opstarten als bijvoorbeeld een C++ applicatie van nu. En dan heb ik het niet over een tooltje van 100 KB, maar iets met een codebase van enkele tientalle MB's.

[ Voor 6% gewijzigd door LauPro op 21-05-2005 16:11 ]

[ACM]

LauPro schreef op zaterdag 21 mei 2005 @ 16:00:
Ik zal eens kijken naar IDEA. Momenteel heb ik nog niet zoveel ervaring met Java op server gebied, dat moet ik toegeven. Ik zal dit ook nog even gaan uitzoeken om een volledig beeld te krijgen. Alleen als ik nu al merk dat een C++/QT applicatie qua GUI soms nog sneller is dan een ncurses-'frontend'. Vraag ik me af waar die traagheid vandaan komt bij de Java GUI. Ik kan me niet voorstellen dat het afhandelen van een GUI dermate veel resources vereist dat de zaal zo erg vertraagd wordt.

Juist wel. Althans met de originele gedachte van Java dat het crossplatform moest zijn. Daardoor zijn platform-specifieke optimalisaties erg lastig in te bouwen, waar een native geprogrammeerde en gecompileerde applicatie dat wel heeft.
Ik moet wel toegeven dat ik juist weinig ervaring heb met GUI's in Java of uberhaupt buiten webinterfaces om.

Wat ik probeer aan te geven: als een 'simpele' IDE al zo traag wordt in java, hoe kan een geavanceerd systeem met enkele tientalle modules en enkele tientalle MB's aan code dan nog snel werken in Java? PHP kan dit momenteel voor zoveer ik weet, maar met Java durf ik het gewoon niet aan nog. Maar ook speelt een klein stukje onweten, ik zal dit uit gaan zoeken.

Als de GUI-performance al wat gemankeerd is in Java en je die "simpele IDE" met een behoorlijk complexe GUI gaat gebruiken voor je performance-beoordeling, dan komt Java inderdaad niet zo goed uit de verf

Iig, kijk hier maar eens naar: http://www.kdevelop.org/i...ilename=3.0/features.html

Het is ook alweer even geleden dat ik KDevelop voor het laatst open heb gehad zo te zien

Kijk, dat Java iets trager is als je de cijfertjes gaat vergelijken met een native C++ app vind ik niet zo erg, dat is PHP of een .NET applicatie ook. Maar het gaat er om dat wanneer iets significant 'traag' is (dus 30+ seconden om op te starten) dat mijn vertrouwen dan wat geschaad wordt. Dan kan je wel zeggen van 'dat is niet de juiste vergelijking'. Maar wat is er precies dan traag? Alleen de GUI? Java is dacht ik in eerste instantie ontworpen voor een goede GUI op allemaal platformen, raar dat dit dan juist het traagste punt zou zijn.

Die .NET-omgeving is leuk dat je dat noemt. Want dat duurt (de eerste keer), vziw ook tamelijk lang om te starten omdat de complete VM opgestart moet worden, ipv alleen de applicatie erin. Daarnaast is Java natuurlijk een ByteCode-taal met als gevolg dat dat nog bij het eerste gebruik omgezet moet worden naar machine code. Dat soort dingen zorgt voor een redelijk slome start. Overigens is daar met java 5 meen ik al het een en ander aan verbeterd en met 6 zal daar nog wel meer aan gesleuteld worden.
Echter is juist de opstarttijd niet relevant bij applicaties die daarna uren draaien. Het is wat vervelend als je daemon er 1 minuut ipv 20 seconde over doet om op te starten, maar als ie daarna weken lang achter elkaar blijft draaien waren was het uiteindelijk minder dan een promille verschil.

De GUI noemde ik net al en is niet Java's sterkste punt op het gebied van performance, wel wordt ook die met elke versie significant sneller.

Bij mijn weten is dus vooral het opstarten van een java-app iets dat wel even kan duren, afhankelijk van hoeveel libraries er geladen en geparsed moeten worden en hoeveel eigen code er in het begin gecompileerd moet worden en dat soort dingen.
De performance van de GUI is geloof ik vooral ook afhankelijk van welke Java versie je hebt (liefst 5) en welke libraries er gebruikt en hoe die gebruikt worden.

Dat je niet meer met &'s kan werken is dan nieuw voor mij, ik gebruik ze nog volop. Zou je een voorbeeld kunnen geven?

Dat kan een beperking van een RC geweest zijn, maar het ging om constructies als:

PHP:

function test(&$var)
{}
// en:
$object =& new Object();

Welke er allemaal niet meer werkten weet ik niet, maar ik weet wel dat ik alle &'s eruit gehaald had in React omdat ik er zoveel parse errors op kreeg... En daarna werkte het toen nog steeds niet. Je kan je dan vast wel voorstellen dat ik PHP5 op dat moment (het was nota bene een RC) aan de kant heb gezet.

@B-Man: PHP van 4 jaar geleden idd niet klaar om 24/7 te draaien. Tegenwoordig met PHP5 (ja ga ik weer ) wordt je code geoptimaliseerd en een gecompileerd door PHP. Het is niet meer zo dat bij elke request het script opnieuw geparsed wordt e.d., dat haalt hij allemaal uit het geheugen.

Heb je daar meer info over voor me?

Maar nogmaals voor de duidelijkheid: ik heb diversie dingen in Java gemaakt en ik ben momenteel ook met een vrij grote Applicatie weer bezig. Ik ben geen tegenstander van Java alleen ik denk dat het nog wel even duurt voordat alle Java applicaties ook zelf zo lekker snel opstarten als bijvoorbeeld een C++ applicatie van nu. En dan heb ik het niet over een tooltje van 100 KB, maar iets met een codebase van enkele tientalle MB's.

Zolang de JVM niet standaard in je geheugen achterblijft zoals de .NET-VM zal het niet gebeuren dat het zo snel opstart, wel sneller door diverse trucjes, maar in de basis altijd trager dan een C++-app. Overigens is de .NET-VM sowieso een betere vergelijking dan C++-apps
Maar zoals gezegd is de opstarttijd in veel gevallen eigenlijk helemaal niet zo relevant, het gaat juist vooral om de responsiviteit van de interface tijdens het werken ermee. En ja, die is bij veel grote Java-apps ook wel wat ondermaats.

[B-Man]

Laupro: je doelt neem ik aan op de (betaalde) tools van Zend? Ik draai een groot project op alle tools die zend verkoopt, dus ook daar heb ik ervaring mee. Ik ontwikkel dan ook dagelijks in PHP, dus toen ik hierboven aangaf PHP niet klaar te vinden voor 24/7 server apps, doelde ik _ook_ op de huidige versie van PHP. Waar ik op doel zijn exact de dingen waarmee dit topic begon: pas vanaf versie 5 krijg je netjes een exception bij overmatige recursie (mogelijke infinite loop).
Juist omdat PHP zo 'losjes' schrijfbaar is, vind ik het heerlijk voor ad-hoc ontwikkeling van webprojecten.
Maar goed, dit is natuurlijk allemaal mijn mening. Ik zou zelf geen belangrijke serversoftware in PHP ontwikkelen, aangezien er vanwege de ruimte die de omgeving biedt veel minder garanties zijn omtrent stabiliteit en zekerheid.

Overigens vind ik de snelheid van java ook allang niet meer achterblijven. Ik draai al een tijdje op 1.5.0, en dat is stukken sneller dan 1.4.x, helemaal als het aankomt op opstarttijden & GUI-zaken. Vanaf 1.5 worden de class library dan ook gedeeld tussen alle actieve virtual machines, waardoor deze niet voor elke JVM geladen hoeft te worden.

Overigens is m.b.v. SWT (zie eclipse) ook een zeer snelle GUI in java te bouwen, al zijn er een hoop java-puristen die het gebeuren afkeuren vanwege het platform-afhankelijke karakter. De eigen Java GUI's waren in het verleden gewoon traag, en IBM is in dat gapende gat gesprongen.

-- edit:
Ik heb overigens ook een tijdje een eigen window manager ontwikkeld (C++) in KDevelop, maar vond dat pakket magertjes, op zijn zachtst gezegd. Al is dat wel een jaar of twee geleden, misschien dat er in de tussentijd een hoop veranderd is.

[ Voor 9% gewijzigd door B-Man op 22-05-2005 16:37 ]

[LauPro]

ACM schreef op zaterdag 21 mei 2005 @ 17:17:
Ik moet wel toegeven dat ik juist weinig ervaring heb met GUI's in Java of uberhaupt buiten webinterfaces om.

Dat is bij mij juist omgekeerd , ik zal het nog wel even uitzoeken om tot een goed oordeel te komen.

Als de GUI-performance al wat gemankeerd is in Java en je die "simpele IDE" met een behoorlijk complexe GUI gaat gebruiken voor je performance-beoordeling, dan komt Java inderdaad niet zo goed uit de verf

Mja hoe het dus ook zij, ik vind die IDE als ik hem vergelijk met KDevelop niet zo bijster complex. Misschien iets meer functies en *misschien* iets beter OO.

Die .NET-omgeving is leuk dat je dat noemt. Want dat duurt (de eerste keer), vziw ook tamelijk lang om te starten omdat de complete VM opgestart moet worden, ipv alleen de applicatie erin. Daarnaast is Java natuurlijk een ByteCode-taal met als gevolg dat dat nog bij het eerste gebruik omgezet moet worden naar machine code. Dat soort dingen zorgt voor een redelijk slome start. Overigens is daar met java 5 meen ik al het een en ander aan verbeterd en met 6 zal daar nog wel meer aan gesleuteld worden.
Echter is juist de opstarttijd niet relevant bij applicaties die daarna uren draaien. Het is wat vervelend als je daemon er 1 minuut ipv 20 seconde over doet om op te starten, maar als ie daarna weken lang achter elkaar blijft draaien waren was het uiteindelijk minder dan een promille verschil.

Mja dat vind ik niet zo erg, je kan in debugmodules werken, dat gaat een stuk sneller tijdens design-time. Met die redenatie zou C++ ook afvallen, ooit wel eens KDevelop gecompileerd ? Daar is zelfs mijn pc ruim 30 minuten zoet mee .

De GUI noemde ik net al en is niet Java's sterkste punt op het gebied van performance, wel wordt ook die met elke versie significant sneller.

Dat heb ik ook al ondervonden, echter ik blijf bij mijn punt dat het over 5 jaar pas op een niveau is wat je nu van een C++/QT-applicatie kan verwachten (dus puur GUI-snelheid e.d.)

Je kan je dan vast wel voorstellen dat ik PHP5 op dat moment (het was nota bene een RC) aan de kant heb gezet.

Klopt, dat zou ik ook niet pikken. Maar daarom zet ik ook nooit (of probeer ik nooit) RC's en Alpha/Beta etc in productieomgevingen. En zeker in dit geval zal Parse ondersteuning moeten geven voor PHP5 en niet dat jij de zaak moet gaan replacen. Ik neem aan dat Parse op de hoogte van PHP5 en wat het allemaal kan. Wat je nu in principe doet is hetzelfde als je nu een Beta van Longhorn pakt en die vervolgens helemaal af kraakt omdat de TV-kaart drivers hem laten crashen. Een RC moet je niet al te serieus nemen. Vaak brengt men op het laatste moment nog grote veranderingen door. Bovendien heeft het ook geen enkele zin om je code af te stemmen op een RC, want in de final zul je zien dat ze het weer hebben aangepast. Ik ben pas met PHP5 begnonen toen hij "stable" uit was, dan zijn de grootste bugs en veranderingen voorlopig even van de baan.

Heb je daar meer info over voor me?

Het probleem is dat dit stukje door Zend wordt geleverd en dat er niet al teveel over vrij is gegeven, echter omdat het open source is kan je het wel opzoeken in Zend/zend_compile.c bijvoorbeeld. Daar zijn een aantal functies welke de PHP-code eenmalig licht 'compileren' waardoor deze makkelijker af te handelen. Geen zwaar proces (of je moet een PHP-file van 10 MB hebben oid ). Maar toch wel aanmerkelijk verschil. Wat trouwens wel gedocumenteerd is is dat er een compilatie-fout kan ontstaan: http://nl3.php.net/errorfunc E_COMPILE_ERROR / E_COMPILE_WARNING. Deze zaten er sinds PHP4 al in, maar voor zover ik weet hebben ze de Zend engine aangepast voor PHP5 waardoor deze nu een iets betere (lees: merkbare) compilatie doet. Wil je echt binaries maken van je PHP-scripts dan moet je de commerciële versie kopen. Ik zal even kijken of ik een in-depth-article kan vinden.

..het gaat juist vooral om de responsiviteit van de interface tijdens het werken ermee. En ja, die is bij veel grote Java-apps ook wel wat ondermaats.

Dat klopt, het is op zich niet zo erg als een website 5 minuten nodig heeft om op te starten, maar ik had het meer over applicaties. Toch ben ik wel benieuwd naar het snelheidsverschil tussen zo'n 'Java-request' en die van bijvoorbeeld PHP.

@B-Man: Met een platform doel ik op een stel functies waarmee je bijvoorbeeld uitvoer werkt. Maar ook een format van includen eventueel een module-systeem etc (beetje vergelijkbaar met ASP waar je een Request/Response-object hebt). En zeker dus ook de code (BL), lay-out en content scheiden.

Natuurlijk kan je PHP met allemaal dingetjes over z'n nek laten gaan, alleen ik vraag me af of je beter af ben met een 'Stack overflow' error. Kijk dat deze constructie (die ik voorstelde) niet deugde dat snapte ik zelf ook wel. Wanneer je in Java een Applet met 100.000 buttons init dan denk ik dat je VM ook wel over z'n nek gaat . Gewoon een kwestie van 'niet-netjes' programmeren wmb.

Mja 'java-puristen' of niet. Als je een taal kiest juist vanuit het oogpunt om platform onafhankelijk te zijn, en vervolgens gooi je er componenten in die zo afhankelijk als de pest zijn dan ben je niet zo goed bezig imo.

Inmiddels is KDevelop een stuk uitgebreider moet ik zeggen. Als ik even de changelog er op na kijk dan was KDevelop 2 jaar geleden een uitgebreide Kate met een compile-functie, en nu is het imo al een echte IDE al hoewel er nog veel moet gebeuren (PHP5 support bijvoorbeeld ).