[ALG] execution time, wat is gezond?*

[Verwijderd]

Al die parse time scriptjes zijn wel heel leuk maar pas nuttig als je vergelijkings materiaal hebt.

Kan er een indicatie gegeven worden met een tijd wanneer de parse tijd echt te groot is in bepaalde gevallen?

Wat is/was bijvoorbeeld de parsetijd van dit forum? Is zeker niet meer na te gaan (vroeger kon je dat nog onderaan de pagina zien)?

Hoe sneller de CPU, groter het geheugen hoe sneller het is mag ik aannemen?

Ik heb een stel classes met daarin een zooitje functies. Elke class is een los bestand, daarin wordt vaak weer een andere andere class bestand geinclude.
Er wordt 1 class bestand in de pagina van de applicatie geinclude, maar omdat deze bestand ook weer een include naar andere classes heeft wordt gewoon alles wel ingeclude . En deze hele grote include kost al veel tijd (0,12 seconden, is dit normaal?), en dan heb je nog niet eens de tijd van de uitvoer ervan.


Wat zijn de tips & tricks om dit sneller te maken?

Want nu blijkt wel weer dat het gebruik van classes (OOP) dus wel langzamer is dan wat functies in de pagina direct te doen.

[Mischa_NL]

Parse tijden van dit forum zijn (nu):

Total: 0,134 | Incl: 0,056, Init: 0,074, Action: 0,065 | DB: 0,03/20, Tpl: 0,024

Includen dat 0.12 seconden kost zonder dat er iets gebeurd? Lijkt me raar hoor.

[gorgi_19]

Verwijderd schreef op maandag 03 januari 2005 @ 20:38:
Al die parse time scriptjes zijn wel heel leuk maar pas nuttig als je vergelijkings materiaal hebt.

Kan er een indicatie gegeven worden met een tijd wanneer de parse tijd echt te groot is in bepaalde gevallen?

Wat is/was bijvoorbeeld de parsetijd van dit forum? Is zeker niet meer na te gaan (vroeger kon je dat nog onderaan de pagina zien)?

Nu nog steeds; doe maar eens view source

Hoe sneller de CPU, groter het geheugen hoe sneller het is mag ik aannemen?

Hangt er van af wat de zwakste schakel is

Want nu blijkt wel weer dat het gebruik van classes (OOP) dus wel langzamer is dan wat functies in de pagina direct te doen.

Onderhoudbaarheid van code staat meestal op gespannen fout met meest snelle code.

[Sybr_E-N]

Verwijderd schreef op maandag 03 januari 2005 @ 20:38:
Al die parse time scriptjes zijn wel heel leuk maar pas nuttig als je vergelijkings materiaal hebt.

Kan er een indicatie gegeven worden met een tijd wanneer de parse tijd echt te groot is in bepaalde gevallen?
Als het simpele select statements van een database call zijn, en die duren 5 seconden dan klopt er iets niet. Het hangt van de situatie af, wat voor dingen je met de code doet enzo. Maar als je alles goed opzet dan moet het binnen een seconden blijven, tenminste dat vind ik.
Wat is/was bijvoorbeeld de parsetijd van dit forum? Is zeker niet meer na te gaan (vroeger kon je dat nog onderaan de pagina zien)?
Die staan er nog steeds in alleen zijn in HTML uitgecommentaard. Dus even kijken in de bron dan vind je: Total: 0,351 | Incl: 0,076, Init: 0,094, Action: 0,247 | DB: 0,127/25, Tpl: 0,103
Hoe sneller de CPU, groter het geheugen hoe sneller het is mag ik aannemen?
Maakt niet zo heel veel uit bij hobbyprojectjes. Maar zelfs met de geavanceerde technieken kun je de boel nog steeds vernaggelen.
Ik heb een stel classes met daarin een zooitje functies. Elke class is een los bestand, daarin wordt vaak weer een andere andere class bestand geinclude.
Er wordt 1 class bestand in de pagina van de applicatie geinclude, maar omdat deze bestand ook weer een include naar andere classes heeft wordt gewoon alles wel ingeclude . En deze hele grote include kost al veel tijd (0,12 seconden, is dit normaal?), en dan heb je nog niet eens de tijd van de uitvoer ervan.


Wat zijn de tips & tricks om dit sneller te maken?
Er zijn in het verleden al verschllende test geweest met betrekking tot het creeren van een pagina. Wat geeft de GoT seach en/of Google?
Want nu blijkt wel weer dat het gebruik van classes (OOP) dus wel langzamer is dan wat functies in de pagina direct te doen.
Kun je je zelf de vraag stellen en beantwoorden wat OOP inhoud in vergelijking met procedureel programmeren. Wat OOP is en wat je er mee kunt, wat de gedachtegang er achter is zijn boeken vol over geschreven. Daar is ook veel informatie over te vinden.

[eamelink]

Verwijderd schreef op maandag 03 januari 2005 @ 20:38:
Al die parse time scriptjes zijn wel heel leuk maar pas nuttig als je vergelijkings materiaal hebt.

Kan er een indicatie gegeven worden met een tijd wanneer de parse tijd echt te groot is in bepaalde gevallen?

Met het huidige breedbandaanbod maakt de snelheid natuurlijk een groter gedeelte uit van de totale snelheidsbeleving van de gebruiker dan vroeger.

Ik zou heel ruwweg zeggen een halve seconde maximaal. Anders wordt het traag surfen. Bedenk dat de browser pas requests voor stylesheets en plaatjes kan doen als de pagina binnen is.

Wat is/was bijvoorbeeld de parsetijd van dit forum? Is zeker niet meer na te gaan (vroeger kon je dat nog onderaan de pagina zien)?

Tienden van een seconde ongeveer.

Hoe sneller de CPU, groter het geheugen hoe sneller het is mag ik aannemen?

CPU zal meestal meer schelen dan geheugen.

Ik heb een stel classes met daarin een zooitje functies.
Elke class is een los bestand, daarin wordt vaak weer een andere andere class bestand geinclude.

Waarom zou je dat niet centraal doen?

Er wordt 1 class bestand in de pagina van de applicatie geinclude, maar omdat deze bestand ook weer een include naar andere classes heeft wordt gewoon alles wel ingeclude . En deze hele grote include kost al veel tijd (0,12 seconden, is dit normaal?), en dan heb je nog niet eens de tijd van de uitvoer ervan.

Mwoah, het is overkomelijk.

Wat zijn de tips & tricks om dit sneller te maken?

Je zou bijvoorbeeld alle klassen in 1 filetje gooien en die includen. Of gewoon alles wat je nodig hebt in 1 grote php file gooien. Dit kan je natuurlijk ook automatiseren. Een progje of een script dat je sources in elkaar gooit.

Als je echter vaak lang niet alle klassen nodig hebt, dan zou het kunnen dat het parsen van alles waaronder het onnodige meer tijd kost dan het parsen van weinig en het hoognodige log includen. Maar dat weet ik niet zeker, zou je moeten benchen

Want nu blijkt wel weer dat het gebruik van classes (OOP) dus wel langzamer is dan wat functies in de pagina direct te doen.

Mwoah, het includen van files en dergelijke heeft vrij weinig met oop in het algemeen te maken.

Maar inderdaad vertraag je je programma/script meestal wel met een OO aanpak. Maar als dat verschil maar weinig is en de onderhoudbaarheid en herbruikbaarheid van de code veel groter wordt, dan is dat een klein verlies

gorgi_19 schreef op maandag 03 januari 2005 @ 20:42:
Onderhoudbaarheid van code staat meestal op gespannen fout met meest snelle code.

Op gespannen fout? Leg eens uit

[gorgi_19]

eamelink schreef op maandag 03 januari 2005 @ 20:56:
Op gespannen fout? Leg eens uit

EfBe schreef op donderdag 02 september 2004 @ 11:48:
[...]

Dit is een totaal andere discussie. Als iedere cycle telt, zijn alle consessies geoorloofd, en gebruik je dus bv geen tier-ed model, maar prak je bv een datareader direct in de gui zodat deze sneller opbouwt.

Jouw situatie die je schetst met een database waar A alleen uit leest en B, C en D in schrijven, is wat Microsoft bv heeft onderzocht en wat als uitgangspunt is genomen voor Yukon: men is beter af in zo'n situatie waarbij men 2 databases gebruikt: 1 voor A en 1 voor B, C en D. Tenzij natuurlijk A direct moet kunnen lezen wat B, C en D schrijven. In dat geval heb je gewoon te leven met de limieten die dat oplevert.

Verder is de dicussie omtrent performance leuk, maar ondergeschikt. Zodra je consessies gaat doen om maar meer performance te halen, betaal je een prijs voor die consessies: minder onderhoudbaarheid en soms hogere complexiteit in je applicatie. Het lullige is dat men dat niet beseft. Men wil EN top performance EN top onderhoudbaarheid EN een erg lage complexiteit. En dat alles ook nog eens supergemakkelijk te realiseren. Echter hoe meer performance je wilt, hoe meer je aan gemak en onderhoudbaarheid moet inleveren.

Constante = performance * onderhoudbaarheid (waarbij performance en onderhoudbaarheid >=1)

Waarom normaliseert men een datamodel uit? voor leesacties (en voor schrijfacties ook) is het niet de snelste benadering. Zomaar een voorbeeld. Men gaat dan wel steevast roepen "Ja maar normaliseren is logisch, dat is correct", maar zo simpel ligt het niet: als elke cycle telt is ook elke consessie geoorloofd, immers performance is het enige doel.

Wil je dus performance, dan ben je klaar met deze discussie. Kom dan echter niet aan met een huilverhaal dat je na 2 jaar 2 dagen per week zit te vloeken omdat het systeem zo verschrikkelijk slecht inelkaar is gezet.

Even een quote van Efbe; legde het goed uit

[Verwijderd]

gorgi_19 schreef op maandag 03 januari 2005 @ 21:00:
[...]


[...]

Even een quote van Efbe; legde het goed uit

De uitdrukking is `op gespannen voet', ik denk dat eamelink daar op doelde .

[gorgi_19]

Verwijderd schreef op maandag 03 januari 2005 @ 21:10:
[...]


De uitdrukking is `op gespannen voet', ik denk dat eamelink daar op doelde .

offtopic:
Mag hij dat eerder zeggen..

* gorgi_19 beetje brak van het proggen atm

[Verwijderd]

ik heb zo rond de 0.24 sec met een programma van mij, maar de code is nog niet ge-optimized, ik heb er nog wat ruwe dingen, flants functies .

Maar dit is dan wel op mijn eigen langzame desktop met apache +php +mysql. Dat zal ook wel veel uitmaken.

[ Voor 28% gewijzigd door Verwijderd op 03-01-2005 21:44 ]

[chem]

Er is nog een heel stuk tussen source die niet te onderhouden is, en source die niet presteert.

Met een line-by-line timer (er zijn daar zend extention's voor) kan je goed inzicht krijgen in je applicatie. Bij bijvoorbeeld constructors, includes, connects of andere algemene handelingen is vaak een winst te behalen door simpelweg code te vervangen door, voor de taal, sneller te verwerken code.

Dat vereist vooral inzicht in de parser, PHP en soms het OS - en is iets wat je op een gegeven moment vanzelf gaat doen.

Profiling kan soms veel winst bieden door kleine zaken te verbeteren - daarmee word je app niet onhandelbaar of chaotisch.

[_Thanatos_]

Je moet denk ik ook niet vergeten dat je niet "zomaar" je parsetijd moet meten. Je kan op je dev-server wel doodleuk 0,12 seconden parsetijd hebben, maar de live-server zou weleens andere specs kunnen hebben. Dat is overkomelijk, maar op de live-server heb je best kans dat er meer dan één persoon op je website bezig is, want kan resulteren in hogere parsetijden.

Of test je op je live-server?

[Verwijderd]

Ik test het op mijn dev-server, en dat is niet zo'n hele snelle.

Ik heb even wat aan mijn classes gesleuteld, en code wat niet presteert weer preseterend gemaakt en nu haal ik gemiddeld 0.10 sec (voorheen 0.24 sec ). Dat vind ik wel een hele snelheid winst gezien dat het een vrij grote applicatie is. . Ik blijf doorsleutelen want ik geloof dat het nog wel sneller kan.

[Verwijderd]

Ik zit zelf op 30ms, en dan wordt er meerdere malen een "include" gedaan, lookups in een soortevan fork cache, en diverse database calls. Met static caching zit ik op 20ms en memory caching 16ms. Loadtests haalden +/- 285 req/sec bij een volle bak aan bezoek.

Het is voor de average website totaal onbelangrijk ook. Het gaat pas tellen als je veel bezoek mag ontvangen.

[Verwijderd]

Verwijderd schreef op dinsdag 04 januari 2005 @ 14:03:
Ik zit zelf op 30ms, en dan wordt er meerdere malen een "include" gedaan, lookups in een soortevan fork cache, en diverse database calls. Met static caching zit ik op 20ms en memory caching 16ms. Loadtests haalden +/- 285 req/sec bij een volle bak aan bezoek.

Het is voor de average website totaal onbelangrijk ook. Het gaat pas tellen als je veel bezoek mag ontvangen.

Hoe voer je loadtests uit als ik dat mag vragen?

[Verwijderd]

Verwijderd schreef op maandag 03 januari 2005 @ 20:38:
Want nu blijkt wel weer dat het gebruik van classes (OOP) dus wel langzamer is dan wat functies in de pagina direct te doen.

Waarom noem je dit topic eigenlijk [alg]???

[zeur mode]
In het algemeen heb je helemaal geen classes of functies in een pagina; in het algemeen heb je helemaal geen pagina. Dat is web specificiek.

Tevens is niet alles parsen. Parsen is geen algemeen wordt wat 'verwerken' of 'iets doen' ofzo betekent. Parsen (parseren), is alleen het ontleden van een structuur. Het werk wat je daarna doet, maar voor de executie, is strikt genomen geen parsen. Dit kan bijvoorbeeld het opbouwen van een syntax tree, het uitvoeren van semantical checks en code generatie zijn. Dit laatste in het geval van niet geinterpreteerde talen.

[/zeur mode]

[Verwijderd]

Verwijderd schreef op dinsdag 04 januari 2005 @ 14:51:
Hoe voer je loadtests uit als ik dat mag vragen?

Ik voer ze op zowel de goede manier (load testing), normaal bezoek en realistische patronen testen, als op de hardhandige manier (stress testing), lomp requests afvuren en kijken wanneer die gaat huilen uit.

Voor gratis software heb je oa OpenSTA, WAST, en voor betaalde software kun je kijken naar Segue Silk Performer, OpenLoad, E-Load. Voor de producten van Macromedia wordt Segue Silk Performer gebruikt.

[ Voor 5% gewijzigd door Verwijderd op 04-01-2005 15:07 ]

[Verwijderd]

Verwijderd schreef op dinsdag 04 januari 2005 @ 14:56:
[...]
Waarom noem je dit topic eigenlijk [alg]???

Typisch voor een PHPer. Net zoiets als dat voor veel mensen een computer gelijk staat aan Windows.

Tevens is niet alles parsen.

Het valt me inderdaad steeds vaker op dat parsen een soort algemene term wordt. Net zoiets als in het gewone taalgebruik "de dinges op de dinges zetten".
Je ziet dit voornamelijk door PHPers gebruikt worden die natuurlijk geen flauw benul hebben van welke stappen er allemaal achter de schermen plaatsvinden.*

Aan de andere kant zie je het toch ook wel voorkomen bij echte programmeurs die bijvoorbeeld van XML gebruik maken; al het werk wat tussen de begin en eind tag van het document gedaan wordt heet dan parsen en de totale tijd die er verstrijkt tussen het aanroepen van de XML parser op een document en de return van die call heet dan parse-time. Ik moet toegeven dat ik me daar zelf ook wel eens schuldig aan maak.

Dit is een een beetje verwarrend vanwege het feit dat veel programmeurs hun code zo opzetten dat bijvoorbeeld correctheids checks en transformaties tijdens het SAX parsen worden gedaan. Andere programmeurs plaatsen de ge-parse-te tekst meteen in eigen datastructuren, en doen de verdere stappen na het parsen. Dit laatste komt meer overeen met de parse-time die je zou meten als je zou DOM parsen. Je meet dat de tijd van de aanvraag aan de XML parser tot de teruggave van de DOM structuur als parse-time.

Maar ik moet toegeven dat ik PHP ook niet goed ken. Mischien dat in PHP jargon inderdaad het hele transformatie proces van een PHP source file tot executeerbare of interpreteerbare code wel parsen heet.

* _{PHPers die parsen op deze manier gebruiken hebben geen flauw benul, natuurlijk niet PHPers in het algemeen.}

[gorgi_19]

Modbreak:

Voor dat mensen nog verder gaan ranten op [ALG], volgens mij heb ik dat zelfs in de titel gezet.
En om gelijk een reatie te geven op:

Typisch voor een PHPer. Net zoiets als dat voor veel mensen een computer gelijk staat aan Windows.

De laatste keer dat ik iets met PHP heb gedaan, toen was PHP 3 net uit

[Verwijderd]

Een moderator heeft inderdaad [ALG] in mijn topic titel gezet, ik heb daar geen problemen mee. Het ging in dit specifiek geval toevallig om php maar het kan eigenlijk elk scripting language zijn.

Ik heb al behoorlijk veel van de parse tijd af weten te krijgen en 1 tip is:

Doe NOOIT: SELECT *

geef gewoon op welke attributen je wilt hebben, dat scheelt ook al wat tijd, niet zo heel veel, maar juiste deze kleine dingetjes hebben bij mij in totaal al 0.15 sec er ah gehaalt.. dat vidn ik nog al wat

[Grijze Vos]

Verwijderd schreef op dinsdag 04 januari 2005 @ 14:03:
Ik zit zelf op 30ms, en dan wordt er meerdere malen een "include" gedaan, lookups in een soortevan fork cache, en diverse database calls. Met static caching zit ik op 20ms en memory caching 16ms. Loadtests haalden +/- 285 req/sec bij een volle bak aan bezoek.

Hoe heb je dat caching gedaan? Dat lijkt me ontzettend interessant. Zeker dat memory caching. (Heb er zelf al wat over nagedacht.)

[Verwijderd]

Al die topics over performance (we hebben het over *PHP* ) gaan toch helemaal nergens over. Het enige topic wat ik ooit gezien heb hier, waar het zinvol was, is deze:
[rml][ C/C++] Gaussian en Gauss-Jordan eliminatie performance[/rml]

Als een applicatie echt te langzaam gaat (hierboven wordt een halve seconde genoemd (er zijn uitzonderingen (zoals bijv. vergelijkingssites))), dan zorg je eerst dat het algoritmisch gezond is (ook: dingen parallel doen, etc.), en als dat zo is, en en het is nog steeds te langzaam, dan zou je eens een ander taaltje (assembly ofzo) op kunnen zoeken. Assembly is is mijn ogen alleen zinvol voor mediasoftware, en hardware interface code (en compilers). Ik hoop dat nooit iemand hier meer een topic over opent. Waarschijnlijk staat er ook wel iets in de FAQ hierover, en anders zijn er nog wel een miljoen mensen die je exact hetzelfde kunnen vertellen.

[Verwijderd]

Dat hangt helemaal af van de gewenste columns. Als je alles graag wilt hebben boeit het voor een goede RDBMS niet of je * of een opsomming van alle columns doet. Als je niet alles wilt hebben ben je gewoon aan het prutsen. In mijn geval vuur ik voornamelijk stored procedures af die specifiek voor de applicatie zijn getuned. Deze worden dan ook overall uitgevoerd onder de 0ms, tenzij het een full text search betreft maar ook daar praat je over hoogstens een paar ms.

Ik heb het qua language trouwens hier over CFMX6.1.

[ Voor 8% gewijzigd door Verwijderd op 04-01-2005 23:52 ]

[damouzer]

Verwijderd schreef op dinsdag 04 januari 2005 @ 23:41:
Een moderator heeft inderdaad [ALG] in mijn topic titel gezet, ik heb daar geen problemen mee. Het ging in dit specifiek geval toevallig om php maar het kan eigenlijk elk scripting language zijn.

Ik heb al behoorlijk veel van de parse tijd af weten te krijgen en 1 tip is:

Doe NOOIT: SELECT *

geef gewoon op welke attributen je wilt hebben, dat scheelt ook al wat tijd, niet zo heel veel, maar juiste deze kleine dingetjes hebben bij mij in totaal al 0.15 sec er ah gehaalt.. dat vidn ik nog al wat

Ook als je alle velden nodig hebt??

[ANdrode]

Verwijderd schreef op dinsdag 04 januari 2005 @ 23:41:
Ik heb al behoorlijk veel van de parse tijd af weten te krijgen en 1 tip is:

Doe NOOIT: SELECT *

geef gewoon op welke attributen je wilt hebben, dat scheelt ook al wat tijd, niet zo heel veel, maar juiste deze kleine dingetjes hebben bij mij in totaal al 0.15 sec er ah gehaalt.. dat vidn ik nog al wat

Ik geloof dat deze discussie wat dieper gaat, en eigenlijk ook taal-onafhankelijk is.
Verder:
Indices helpen ook, mits goed gebruikt.
Het softwarematig doen van sub-query's (Mysql 3, host had geen postgres), door heel grote where clauses (en een opvraagfuncite, en querybouwer) is trouwens ook niet goed.

[Verwijderd]

Verwijderd schreef op dinsdag 04 januari 2005 @ 23:41:
Een moderator heeft inderdaad [ALG] in mijn topic titel gezet,

Nouja, dan bij deze mijn excuses voor de eerste 'rant'. Het probleem is inderdaad algemeen maar de post zelf was wel degelijk op PHP gericht.

Ik heb al behoorlijk veel van de parse tijd af weten te krijgen en 1 tip is:

Doe NOOIT: SELECT *

Volgens mij heb jij het of nog steeds niet begrepen, of bovenstaande post niet gelezen, of je hebt het nu over de pure SQL parsing (die meestal maar een fractie van de planning en execution time in beslag neemt).

Zoals nu wel duidelijk moge zijn:

PARSING IS NIET DE GEHELE PROCESSING TIME VAN JE PAGINA

Als het nu nog niet duidelijk is

Wat er in PHP ook tot parsing gerekent wordt, de execution time van de logica op de pagina (statements (berekeningen, loops, etc), en dus indirect ook SQL queries) hoort niet bij de parse-time.

De algehele processing time van je pagina wordt meestal "overal processing time" genoemt (vanaf de kant van de server gezien), of response time (meer vanaf de client gekeken).

Dit zijn 2 heel verschillende tijd metingen. Als ik de titel staat "parse-time" is het misleidend om over "execution-time" te gaan praten.

Overigens om toch even op je comment zelf in te haken, "select *" lijkt me nogal afhankelijk van de DB en resultaat of het sneller is of niet in execution. Het parseert sowiezo sneller omdat het bijna altijd minder tokens zijn

[sorted.bits]

Effe kleine side-note... (mijn kijk op de zaak )

Parsing van pagina's gebruik ik ook vaak, maar daar valt ALLES onder wat er moet gebeuren om die pagina goed op jouw scherm te krijgen.

Interpreter time van een script is zeg maar de tijd die de server nodig heeft om door de PHP code heen te lopen en een valide HTML pagina op te leveren.

Zo maak ik het onderscheid altijd. Verder vind ik henk wel een beetje neerbuigend doen over PHP 'programeurs'.

Typisch voor een PHPer. Net zoiets als dat voor veel mensen een computer gelijk staat aan Windows.

Deze dingen kan je beter voor je houden als je niets beters te melden hebt.

[ Voor 10% gewijzigd door sorted.bits op 05-01-2005 00:07 ]

[gorgi_19]

sorted.bits schreef op woensdag 05 januari 2005 @ 00:06:
Zo maak ik het onderscheid altijd. Verder vind ik henk wel een beetje neerbuigend doen over PHP 'programeurs'.
...
Deze dingen kan je beter voor je houden als je niets beters te melden hebt.

Hier heb ik al eerder op gereageerd; kunnen we deze discussie nu staken en weer verder gaan met het eigenlijke onderwerp?

[Verwijderd]

Het gaat hier om milliseconden performance voordeel/nadeel. Als we het puur hebben over web pagina's, zijn dat verwaaloosbare verbeteringen/verslechteringen. Door de client plaatjes, javascript, stylesheets, e.d. te laten cachen krijg je al een veel grotere performance

[Verwijderd]

sorted.bits schreef op woensdag 05 januari 2005 @ 00:06:
Parsing van pagina's gebruik ik ook vaak, maar daar valt ALLES onder wat er moet gebeuren om die pagina goed op jouw scherm te krijgen.

Correctie: volgens -jou- valt alles daar onder.

Tip:
Zoek eens de betekenis van to parse op in het woordenboek. Doen!


Maar aangezien het dus toch over processing time gaat, is het mischien wel nuttig om op te merken dat tegenwoordig micro optimalisaties vaak niet meer de moeite waard zijn. Vroeger toen ik op de C64 aan het hacken was in assembly telde je elke cycle en elke byte, maar de tijden zijn erg veranderd.

Zoals boven vernoemt moet je zeker naar je algorithmen kijken en de complexiteit daarvan. Dit is zeer belangrijk voor als je problem domain scaled (groter wordt). Heel simpel gezegd wil je exponentiele complexiteit zoveel mogelijk vermijden.

In het SQL geval valt er dikwijls zeer veel winst te halen met de manier waarop je je query schrijft. De planner kan zeker niet alles weten. In een declaratieve taal als SQL zijn er zeer veel mogelijkheden om dezelfde query te omschrijven, maar de performance kan heel veel schelen. Een hele simpele vuistregel is om tabellen zo snel mogelijk klein te maken voordat je een join toepast. Dit geldt bijvoorbeeld zeer sterk als je groupings gebruikt waarbij bij elke group 1 of meerdere velden ge-joined worden van een andere tabel. Je kunt dit met 1 from clause en een uitgebreide where clause doen, maar het is vele malen sneller om het in 2 subqueries te doen en die pas te joinen. Ik heb nog pas een query van >100 seconden naar +- 15 seconden zien gaan door deze eigenlijk simpele optimalisatie.

Voorts moet je ook naar je onderhoudbaarheid, uitbreidbaarheid, leesbaarheid etc kijken. Projecten worden steeds groter. Het loont absoluut om je software architectuur modulair op te zetten en veel de-coupling te doen. Dit betekent dat je een overal framework hebt waarin je functionaliteit delegeert naar afzonderlijke componenten die elk een goed gedefineerde functie duidelijk en clean uitvoeren.

In het algemeen kost de-coupling performance -> je moet door meer lagen heen, en je hebt meer boekhouding te doen. Micro optimalisaties zoals of ++i nu sneller is als i++ vallen daarbij compleet in het niet. Ik kom zelf nog uit een tijd dat je elke functie call probeerde te vermijden omdat dat al 'duur' was. Tegenwoordig breek ik een functie op in tig kleinere functies alleen maar voor de leesbaarheid (en test-baarheid!). Als je systemen >500.000 regels worden wil je zeker niet meer op dezelfde manier werken als toen je app nog 2000 regels totaal was.

[ Voor 3% gewijzigd door Verwijderd op 05-01-2005 00:45 ]

[Verwijderd]

Verwijderd schreef op woensdag 05 januari 2005 @ 00:12:
Het gaat hier om milliseconden performance voordeel/nadeel. Als we het puur hebben over web pagina's, zijn dat verwaaloosbare verbeteringen/verslechteringen. Door de client plaatjes, javascript, stylesheets, e.d. te laten cachen krijg je al een veel grotere performance

Nou het verschil is eigenlijk dat bij het laden van plaatjes de pagina er al is en dat dan de plaatjes nog geladen moeten worden (en dat zie je).
En de server vestuurt pas de pagina als de php applicatie uitgevoerd is, en ik merk dat wel degelijk.

En volgens mij is snelheid winst wel erg belangrijk als we het over zoekmachines hebben. Crawlers zitten op super snelle netwerken, en als de uitvoer tijd van je scipt te lang duurt kan het misschien wel eens tijd zijn voor een no-respone voor de crawler en slaat de pagina over.

[Verwijderd]

Maar, Henk, je blijft ratelen over architectuur en van alles en nog wat, maar bottom line was "wat is een gezonde parse tijd". Kortom, wanneer gaan bezoekers weg omdat het te lang duurt.

Als je het over de winst van optimalisaties etc. wilt hebben moet je gewoon even een nieuw topic openen met onderbouwing.

[ripexx]

Verwijderd schreef op woensdag 05 januari 2005 @ 08:39:
Maar, Henk, je blijft ratelen over architectuur en van alles en nog wat, maar bottom line was "wat is een gezonde parse tijd". Kortom, wanneer gaan bezoekers weg omdat het te lang duurt.

Ach zoplang het niet seconden wordt is het niet zo'n probleem. Je moet je alleen afvragen wat er gebeurt als je een "parse" time van 500ms hebt dat je dan is je capaciteit natuurlijk ook beperkt. Kijk maar eens wat er met Fok is geberut toen met overhaast over moest op nieuwe software. Niets was echt uitgebreid getest. Hierdoor waren de parse tijden op de live omgeving niet meer werkbaar. Je kan dan noodmaatregelen nemen zoals zend-optimerzer (PHP) oid maar dan ben je eigenlijk reactief bezig. Blijkbaar zit er iets in de code wat er voor zorgt dat het niet preformt.

Als je gaat testen, test dan op een represenatieve omgeving. Dit betekend dan ook dat je datasets vergelijkbaar moeten zijn en dat je met tools gaat testen. Dat kan simpel bij apache met ab maar je kan het geheel ook dynamischer maken. Identificier je probleem en ga dan kijken.

Als je het over de winst van optimalisaties etc. wilt hebben moet je gewoon even een nieuw topic openen met onderbouwing.

Als je wil weten wat gezond is moet je ook weten hoe je dat kan bereiken. Het ligt allemaal zo dicht bij elkaar.

Verder is optimalisatie zeer platform (OS, DBMS, taal) afhankelijk. En ben je ook nog eens afhankelijk van hardware. Als je een beetje zoekt op GoT, Zend.com, php.net zal je genoeg artikelen vinden over optimalisatie en wat moet je juist wel doen en wat niet. Dit zelfde geldt ook voor de MySQL.

[Verwijderd]

Verwijderd schreef op woensdag 05 januari 2005 @ 08:39:
Maar, Henk, je blijft ratelen over architectuur en van alles en nog wat, maar bottom line was "wat is een gezonde parse tijd". Kortom, wanneer gaan bezoekers weg omdat het te lang duurt.

Dat is een heel apart issue waar ik noch Henk, noch een van de andere echt over heb gehoord.

Wat is de maximale response time die users pikken?

(en jongens, hou aub op alles parse time te noemen, dat komt echt dom over. Als je serieus met je vak bezig bent gebruik dan ook de juiste termen)


Ik zou zeggen dat zonder het ergens op te basseren (onderzoek ofzo), het zo rond de 2 seconden per pagina licht, met een maximum van 4 seconden. Er zijn vast wel ergens op het net statistieken te vinden die aangeven welk percentage mensen blijft wachten op een pagina bij welke response time.

Zoals jullie mischien weten zijn Java applets grotendeels mislukt doordat de initial time to display zo enorm hoog lag. Het moeten installeren van JREs en het MS, SUN gedoe was nog niets eens het grootste probleem.

Als je het over de winst van optimalisaties etc. wilt hebben moet je gewoon even een nieuw topic openen met onderbouwing.

Beetje vage opmerking. De meeste posts in deze thread gaan precies daar over. Zie ook post van TS over "je moet geen select *" gebruiken. Dat gaat toch echt over winst van optimalisaties. Henk haakt daar uitstekend op in. Ik doe dat zelf ook steeds minder, naar die kleine dingen kijken en vooral oog houden op de grote lijnen. Daar win je op termijn veel meer mee.

ps

Heb ik al gezegd dat niet alles wat een computer doet parsen is?

[Verwijderd]

Verwijderd schreef op woensdag 05 januari 2005 @ 00:59:
[...]

En de server vestuurt pas de pagina als de php applicatie uitgevoerd is, en ik merk dat wel degelijk.

En de server vestuurt pas de pagina als de web applicatie uitgevoerd is, en ik merk dat wel degelijk.

Niet alle web applicaties zijn php applicaties...

[PhoeniX-]

Ik heb mijn CMS'je een aantal jaar geleden eens onder de loep gehouden om zo de parse/laad/whatever tijd te verlagen.
De grootste winst was in mijn geval te behalen met het optimaliseren van de database tabellen. Als je een tabel doorzoekt met 'WHERE naam = '$var'", zet dan een index op 'naam', enzovoort. Het slim toevoegen van Indexen scheelde aanzienlijk.

Een ander punt was het aantal database queries. In sommige gevallen konden meerdere queries in 1 query geplaatst worden en in andere gevallen kon het resultaat hergebruikt worden in plaats van opnieuw dezelfde data uit de database vissen.
Het is natuurlijk heel makkelijk om steeds een standaard functie aan te roepen maar als deze meerdere malen dezelfde data ophoest is het sneller om deze data in een variabele te zetten en deze de volgende keren opnieuw te gebruiken.

[sorted.bits]

Verwijderd schreef op woensdag 05 januari 2005 @ 00:38:
Lang off-topic verhaal

Yup en daarom staat er in mijn post ook "Mijn kijk op het verhaal".

Woordenboek :

code:

parse   Audio pronunciation of "parse" ( P )  Pronunciation Key  (pärs)
v. parsed, pars·ing, pars·es
v. tr.

   1. To break (a sentence) down into its component parts of speech with an explanation of the form, function, and syntactical relationship of each part.
   2. To describe (a word) by stating its part of speech, form, and syntactical relationships in a sentence.
   3.
         1. To examine closely or subject to detailed analysis, especially by breaking up into components: “What are we missing by parsing the behavior of chimpanzees into the conventional categories recognized largely from our own behavior?” (Stephen Jay Gould).
         2. To make sense of; comprehend: I simply couldn't parse what you just said.
   4. Computer Science. To analyze or separate (input, for example) into more easily processed components.

En hieruit maak jij op dat jij gelijk hebt en ik ongelijk ?

[ Voor 104% gewijzigd door sorted.bits op 05-01-2005 11:45 ]

[Verwijderd]

_{Disclaimer: Het volgende is onder voorbehoud en imho, voor het geval ik grove fouten zit te maken of arrogant over kom .}

sorted.bits schreef op woensdag 05 januari 2005 @ 11:41:
[...]
Woordenboek :

code:

   4. Computer Science. To analyze or separate (input, for example) into more easily processed components.

En hieruit maak jij op dat jij gelijk hebt en ik ongelijk ?

Het analyseren van de PHP file is maar een gedeelte van de tijd. De rest van de tijd die nodig is om de pagina te genereren gaat in het uitvoeren van het script zitten. Laten we die voor het gemak execution time noemen. En dan moet het resultaat natuurlijk nog naar de browser (transfer time?).

Ik zou willen poneren dat de tijd die nodig is voor een pagina om bij de gebruiker te komen dus grofweg in 3 categorieën onder te verdelen is:

code:

1. Parse time
2. Execution time
3. Transfer time

1. Parse time
Ik denk (zonder daar eigenlijk tests voor uitgevoerd te hebben), dat deze te verwaarlozen is. Bovendien heb je hier toch geen invloed op, want dit gebeurt allemaal binnen de PHP interpreter. Misschien dat je het iets beter kan maken door je code te compressen, dwz. alles in zo min mogelijk files gooien, commentaar en witruimte er tussenuit, maar zelfs dan betwijfel ik of het resultaat significant is.

2. Execution time
Dit is het grote en interessante gebied waar de optimalisaties te halen zijn, want procentueel gezien gaat hier (wederom waarschijnlijk) de meeste tijd in zitten. In deze stap is het wel van belang dat je algoritmes goed zijn, dat je niet onnodig queriet en dat je resultaten cachet. Waarschijnlijk is dit waar iedereen het over heeft als ze het hebben over `de parse time optimaliseren' en prompt over queries beginnen te praten .

3. Transfer time
Misschien niet het belangrijkst, maar ik zou het ook niet negeren. Je kunt hier niet altijd invloed op uitoefenen: als de gebruiker nou eenmaal een trage verbinding heeft dan valt daar niks aan te doen en gaat het oversturen van de pagina gewoon langer duren. Aan de andere kant moet de server natuurlijk aan een `ph@t' genoege `pip3' hangen om alle clients af te handelen. Je kunt nog truukjes gebruiken als simpele load balancing voor zwaar belaste servers (bijvoorbeeld PHP content van één server af serveren en plaatjes vanaf een andere). En, hoe triviaal het is ook is: hoe groter de content, hoe langer de transfer time. Dus een pagina design met veel plaatjes zal er langer over doen om bij de client te komen dan een pagina met alleen text. Misschien niet helemaal on-topic in dit forum, maar wel relevant.


De serving time van een pagina hangt dus niet af van één enkele factor, maar een combinatie van een aantal zaken waar je in meer of mindere mate invloed op kan uitoefenen.

[Verwijderd]

sorted.bits schreef op woensdag 05 januari 2005 @ 11:41:
[...]
En hieruit maak jij op dat jij gelijk hebt en ik ongelijk ?

Overduidelijk dat jij ongelijk hebt.

OneOfBorg legt het hierboven goed uit en Henk lijkt me ook wel redelijk duidelijk. Ik snap ook niet helemaal waarom je de post van Henk offtopic noemt. Het gaat over het sneller laten draaien van queries en dat kleine lokale optimalisaties niet altijd genoeg opleveren voor de moeite die je er in stopt ( om het maar even kort samen te vatten). Perfect overeenkomend met dit topic dus!

[Verwijderd]

Nog even een vraagje over de echte parse time. Weet iemand misschien of het opbreken van PHP code in meerdere verschillende blokken een negatief effect op de parse time heeft, of dat dit vrijwel verwaarloosbaar is?

Mij lijkt dit:

PHP:

<?php   
   // grote lap code
?>

<html>
...
</html>

efficienter te parsen dan iets dergelijks:

PHP:

<?php /* code */ ?>
<html>
<?php /* code */ ?>
...
<?php /* code */ ?>
</html>
<?php /* code */ ?>

Heeft iemand CONCRETE/OFFICIELE informatie over het effect hiervan op de parse time?

[Verwijderd]

@webswjans
Dat kan je natuurlijk gewoon even meten. Ik denk eigenlijk niet dat het uitmaakt. De hele pagina wordt nl. sowiso geparset, niet alleen de stukken tussen "<?php" en "?>". Alle HTML wordt naar echo's geconverteerd.

Even in het algemeen:

Verwijderd schreef op woensdag 05 januari 2005 @ 00:59:

Nou het verschil is eigenlijk dat bij het laden van plaatjes de pagina er al is en dat dan de plaatjes nog geladen moeten worden (en dat zie je).
En de server vestuurt pas de pagina als de php applicatie uitgevoerd is, en ik merk dat wel degelijk.

Sorry, misschien heb je me niet helemaal begrepen (of ik jou niet natuurlijk ). M'n opmerking was licht-ironisch bedoeld. Maar even serieus: milliseconden gaan optimaliseren slaat natuurlijk helemaal nergens op. De tijd die de browser nodig heeft om de pagina op het scherm te toveren is nog langer, en door plaatjes, stylesheets & scripts te laten cachen en matig te gebruiken, haal je zeker ook een snelheidswinst. Wat ik dus eigenlijk bedoel te zeggen: kijk niet alleen naar je code, maar vooral: maak je niet te druk.

En volgens mij is snelheid winst wel erg belangrijk als we het over zoekmachines hebben. Crawlers zitten op super snelle netwerken, en als de uitvoer tijd van je scipt te lang duurt kan het misschien wel eens tijd zijn voor een no-respone voor de crawler en slaat de pagina over.

Ik neem niet aan dat al na een halve seconde gebeurt

[Verwijderd]

Verwijderd schreef op woensdag 05 januari 2005 @ 14:54:
Nog even een vraagje over de echte parse time. Weet iemand misschien of het opbreken van PHP code in meerdere verschillende blokken een negatief effect op de parse time heeft, of dat dit vrijwel verwaarloosbaar is?

Mij lijkt dit:

PHP:

<?php   
   // grote lap code
?>

<html>
...
</html>

efficienter te parsen dan iets dergelijks:

PHP:

<?php /* code */ ?>
<html>
<?php /* code */ ?>
...
<?php /* code */ ?>
</html>
<?php /* code */ ?>

Heeft iemand CONCRETE/OFFICIELE informatie over het effect hiervan op de parse time?

Speciaal voor jou () heb ik het even gebenchmarked (in een tamelijk primitieve setup, toegegeven).

Wat ik getest heb is het verschil in parsetijd tussen een file die er als volgt uitziet:

PHP:

<? echo "Bliep;" ?>
<br>
<? echo "Bliep;" ?>
<br>

...

En een file die er als volgt uitziet:

PHP:

<?
echo "Bliep";
echo "Bliep";

...
?>
<br>
<br>

De uitvoer is natuurlijk niet precies hetzelfde, maar de verdeling tussen PHP code en HTML code is gelijk (allebei 50/50).

Het benchmarken zelf heb ik gedaan met:

code:

php -l

Dit command syntax-checkt het bestand, dus het lijkt mij dat dat precies de parse time omvat (dat is wel de aanname waaronder deze test wordt uitgevoerd).

Ik heb e.e.a. geautomatiseerd met het volgende script. Ik post het hier, zodat deze test naar believen herhaald kan worden door anderen:

code:

#!/bin/bash
rm oneblock.php
rm mulblocks.php

STMTS=10000

echo %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
echo %% Generating files, stand by...
echo %% \(Number of statements: $STMTS\)
echo %%

# Create multiple blocks file
echo %% Multiple blocks file...
for i in `seq 1 $STMTS`;
do
    echo \<?php echo \"Bliep\"\; ?\> >> mulblocks.php
    echo \<br\> >> mulblocks.php
done

# Create single block file
echo %% Single blocks file...
echo \<?php >> oneblock.php
for i in `seq 1 $STMTS`;
do
    echo echo \"Bliep\"\; >> oneblock.php
done
echo ?\> >> oneblock.php

for i in `seq 1 $STMTS`;
do
    echo \<br\> >> oneblock.php
done

echo %%
echo %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
echo %% Benchmarking
echo %%
echo %% Running single block file
time php -l oneblock.php > /dev/null

echo %%
echo %% Running multiple blocks file
time php -l mulblocks.php > /dev/null

Als ik hem bij mij run is het resultaat:

code:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Generating files, stand by...
%% (Number of statements: 10000)
%%
%% Multiple blocks file...
%% Single blocks file...
%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Benchmarking
%%
%% Running single block file

real    0m0.323s
user    0m0.270s
sys     0m0.050s
%%
%% Running multiple blocks file

real    0m0.465s
user    0m0.390s
sys     0m0.080s

Er is dus inderdaad een verschil in parsetijd, maar het is verwaarloosbaar klein.

Een snelle rekensom levert (0.450-0.300)/10000 = 0.000015 seconden per <?php blok.


Ik heb nog even een snelle test erachteraan gedaan waar de files niet alleen geparsed worden maar ook uitgevoerd, en het verschil is wederom verwaarloosbaar (zelfs even groot ~150ms, wat suggereert dat de execution time van de twee scripts even groot is).

Doe er je voordeel mee, zou ik zeggen

[T-MOB]

Verwijderd schreef op woensdag 05 januari 2005 @ 19:10:
Sorry, misschien heb je me niet helemaal begrepen (of ik jou niet natuurlijk ). M'n opmerking was licht-ironisch bedoeld. Maar even serieus: milliseconden gaan optimaliseren slaat natuurlijk helemaal nergens op. De tijd die de browser nodig heeft om de pagina op het scherm te toveren is nog langer, en door plaatjes, stylesheets & scripts te laten cachen en matig te gebruiken, haal je zeker ook een snelheidswinst. Wat ik dus eigenlijk bedoel te zeggen: kijk niet alleen naar je code, maar vooral: maak je niet te druk.

Milliseconden gaan optimaliseren slaat natuurlijk nergens op als je pagina nauwelijks wordt opgevraagd. Zodra je een druk bezochte site hebt wordt het een ander verhaal, dan moet je het volgens mij procentueel zien: op een script dat 20ms nodig heeft om uitgevoerd te worden is 1ms wél 5%. Dat betekent grofweg dat je met 5% minder hardware klaar bent.

[Verwijderd]

Het hangt geheel af van de situatie of je simpelweg hardware kunt gaan bijplaatsen, of moet gaan refactoren/optimaliseren. Nieuwe hardware is meestal een oplossing om een probleem te maskeren, en persoonlijk heb ik toch regelmatig mbv optimalisaties enorme winsten geboekt. Maar zoals ik al zei, het hangt geheel van de situatie af wat je kan gaan doen.

Meestal worden de grootste vertragingen die ik in andermans sourcecode zie vaak veroorzaakt door het te gortig afvuren van queries, die met een enkele query en nabewerkingen op de resultset in een enkele klap werden opgelost. Qua purisme zou je per object een query moeten afvuren, qua etiquette. Maar in de praktijk slibt een hele applicatie daardoor dicht. Hetzelfde verhaal als dat je wel of niet business logic in stored procedures moet gaan plaatsen. Soms is dat ondanks dat het niet netjes is gewoon een superieure oplossing.

[ Voor 44% gewijzigd door Verwijderd op 05-01-2005 21:25 ]

[Verwijderd]

Verwijderd schreef op maandag 03 januari 2005 @ 20:38:
Al die parse time scriptjes zijn wel heel leuk maar pas nuttig als je vergelijkings materiaal hebt.

Kan er een indicatie gegeven worden met een tijd wanneer de parse tijd echt te groot is in bepaalde gevallen?

Wat is/was bijvoorbeeld de parsetijd van dit forum? Is zeker niet meer na te gaan (vroeger kon je dat nog onderaan de pagina zien)?

Ik kan uit ervaring vertellen dat als de klant belt dat de site zo traag is dat het dan te langzaam is

statestieken en gemeten gemiddelde voor zelvde functionaliteit daar gelaten, komt het altijd neer op hoe snel het aanvoelt.
Voor mij voelde de site opzich niet zo heel zwaar aan, de klant had echter een single ISDN en ik kan me wel voorstellen dat de site dan niet echt vrolijk snel was.

daar spits je dan ook je optimalisatie op aan.
b.v. een aantal plaatjes waren dynamisch dit omdat deze "konden" veranderen.
Om deze reden was er toen standaard een no-caching toegepast om te zorgen dat men altijd de correcte info had.
een simpele manier om deze dan te optimaliseren was om die no-caching aan te passen.

dit simpel als voorbeeld ter illustratie dat optimalisatie niet altijd de zelvde weg hoeft te zijn.

Ik heb een stel classes met daarin een zooitje functies. Elke class is een los bestand, daarin wordt vaak weer een andere andere class bestand geinclude.
Er wordt 1 class bestand in de pagina van de applicatie geinclude, maar omdat deze bestand ook weer een include naar andere classes heeft wordt gewoon alles wel ingeclude . En deze hele grote include kost al veel tijd (0,12 seconden, is dit normaal?), en dan heb je nog niet eens de tijd van de uitvoer ervan.

tsja, 0.12 seconden.
klinkt als best veel.
maar als jouw voledige execution time tegen een minuut aan zit (b.v.) dan zou ik de bottlenek toch ergens anders zoeken.

Wat zijn de tips & tricks om dit sneller te maken?

De beste trick is natuurlijk nog altijd make shift je code analyseren om te kijken waar de meeste tijd naartoe gaat.

in loops b.v. die veel aangeroepen worden is het verstandig om single quotes rond strings te zetten, zodat php deze niet door hoeft te kijken op zoek naar variabelen of speciaale string modifiers/chars (\n \t etc...)

ook zorgen dat na klaar te zijn met de dataset uit een query je deze flushed met behulp van **sql_free_results. Vooral wanneer je met grote datasets eruit trekt kan dit wat preformance schelen.

En als je nou echt een botleneck houd, dan heb je of de foute taal gekozen, of je applicatie logica moet verbeterd worden, of je moet er simpelweg genoegen mee nemen dat het daadwerkelijk zo lang duurt.

Ik heb meerdere applicaties geschreven met een executie tijd van meerdere uren.
Maarja, een backup draaien van een server gaat nu eenmaal niet in een miliseconde.
Nog het converteren van plaatjes.

Verder ligt er nu nog een applicatie in skelet vorm met een executie tijd van 24 uur 7 dagen in de week en met een beetje geluk nog 12 maanden per jaar ook.

Het is maar net waar het voor is.

Want nu blijkt wel weer dat het gebruik van classes (OOP) dus wel langzamer is dan wat functies in de pagina direct te doen.

Moet het ook sneller zijn?
Ik heb b.v. van de week een bepaald programma wat eerst "gewoon" (liniear? iteratief, weet niet precies meer hoe het heet) was omgezet naar OOP.
waarbij grote delen van de achterliggende logica veranderd weren, veel nieuwe mogelijkheden geimplementeerd zijn.
En dit is nu al in een fractie van de tijd geschreven, omdat ik in OOP de structuur en logica veel simpeler voor mezelf kon visualiseren.

Minder uren nu, minder uren als het aangepast moet worden.
en die kosten wegen echt wel op tegen de paar procenten preformance van de applicatie zelf.

offtopic:
Over het hele parse tijd verhaal, een simpele reden dat dit in de PHP hoek vaak te pas en te onpas word gebruikt is simpelweg omdat PHP alles zo'n beetje parse errors noemt.
(wat voledig correct is, immers hij vind de fout terwijl hij de code parsed)
echter krijg je hier wel de neiging van om bij alles wat php doet het parsen te noemen.
Zelfs als je eigenlijk dondersgoed zou moeten weten wat parsen wel en niet is, om dat een leraar zijn tijd verknoeit heeft het je in de treuren uit te leggen.

maar om daar nu zo'n ontiegeloze ophef over te maken vind ik ronduit belachelijk.

[Verwijderd]

T.net zelf noemt het ook parsetime (kijk maar in de status balk als je surft naar tweakers.net) dus ik vindt het maar een beetje praatjesmakerij en patsen met zijne nerdschap.

[Verwijderd]

Verwijderd schreef op donderdag 06 januari 2005 @ 10:00:
T.net zelf noemt het ook parsetime (kijk maar in de status balk als je surft naar tweakers.net) dus ik vindt het maar een beetje praatjesmakerij en patsen met zijne nerdschap.

En omdat alle oma's van de moderne wereld het onderscheid tussen XP en Computer niet kunnen maken noemen we een computer vervolgens dan ook maar XP?

Als dit nou een PHP topic was kon ik nog leven met het feit dat PHPers alles parsen willen noemen, maar dit is toch echt een algemeen topic. Het is in dit geval niet pietluttig, maar verwarrend. Als je de topic title lees, waar gaat het dan over? Je denkt eerst dat het algemeen over parse time gaat, en dat is dus een compiler constructie/language design issue. Echter als je het topic leest blijkt het over performance optimalisaties te gaan. Er komt dan iemand die performance tips geeft en dan komt er weer iemand anders die het offtopic noemt. Etc etc.

Kortom, verwarring alom. Gewoon het beestje bij de naam noemen. Zo moeilijk is het allemaal ook weer niet...

[Janoz]

Even het beestje bij het naampje genoemd (ie titlefix), en nu weer ontopic want het is wel duidelijk dat het hier gewoon over execution time gaat.

[ Voor 46% gewijzigd door Janoz op 06-01-2005 12:52 ]