DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Sowieso is het gewoon dom om je zulke verkeerde dingen aan te leren als in een keer alles in een grote array plempen. Dat schaalt voor geen meter.quote:Op dinsdag 6 september 2011 14:47 schreef Chandler het volgende:
Daar ben ik het dus niet geheel mee eens! juist door overzichtelijk te scripten (programmeren wil ik het niet noemen...) kun je juist geheugen besparen doordat je sneller je 'foutjes' ziet.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Daarom moet je eerst berg werk investeren om je code zo te krijgen dat je dataset dynamisch kunt krijgen. Zelf hoef ik geen query's meer te schrijven. Alleen even de classes aanmaken en die daar heb ik ook een script voor geschreven die dat doet voor mij, dus dat is gewoon een druk op de knopquote:
[..]
Dan nog hoef je helemaal niet perse eerst alle classes op te bouwen en ze daarna te gebruiken, dat kun je prima per row doen. Als het kleine sets data zijn is het zeker geen issue, maar bij grote recordsets wel, dan wil je die echt niet eerst allemaal in 't geheugen opbouwen.
Twee loops is nergens voor nodig, lijkt mij. Maar ik gebruik wel liever foreach-loops dan for-loops, omdat het een simpelere syntax heeft en er daardoor overzichtelijker uitziet.
Dat ben ik met je eens, vandaar mijn voorbeeldquote:
[..]
Sowieso is het gewoon dom om je zulke verkeerde dingen aan te leren als in een keer alles in een grote array plempen. Dat schaalt voor geen meter.
Just say hi!
De tijd dat een server net 100 MB geheugen tekort komt ligt alweer een decennium achter ons. Je redenering klopt ook niet: al voordat mysql_fetch_assoc wordt aangeroepen, zit de hele resultset in het geheugen van de webserver (of in het geheugen van de dbserver bij een unbuffered query).quote:
[..]
Wat bedoel je? Stel elke row is een kb aan data, en je hebt 1000 rows. Het maakt nogal uit of je script 1MB aan geheugen moet alloceren of max 1kb. Vergeet niet dat je zo 100 requests tegelijkertijd af te handelen kunt hebben.
Veel ontwikkelaars vinden het overzichtelijker om de code en de opmaak van elkaar te scheiden, en met een echo en een mysql_fetch_assoc in dezelfde loop gebeurt dat niet.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
quote:Op dinsdag 6 september 2011 14:49 schreef Tijn het volgende:
Twee loops is nergens voor nodig, lijkt mij.
Dat is voor mij inderdaad de reden om alles in 1 array te stoppen. En dan heb je ook 2 loopjes; 1 om de data op te halen en 1 in de template om het te presenteren.quote:
Veel ontwikkelaars vinden het overzichtelijker om de code en de opmaak van elkaar te scheiden, en met een echo en een mysql_fetch_assoc in dezelfde loop gebeurt dat niet.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Leesvoer: http://gathering.tweakers.net/forum/list_messages/1105254
Nog meer: http://www.ukuug.org/events/linux2002/papers/html/php/#section_2
Nog meer: http://www.ukuug.org/events/linux2002/papers/html/php/#section_2
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Het is gewoon niet waar dat die hele resultset per definitie al in 't geheugen zit. Databaseservers zijn daar veel slimmer in. Als 2 queries dezelfde table benaderen hoeft deze niet 2 keer volledig in 't geheugen te zitten.quote:
De tijd dat een server net 100 MB geheugen tekort komt ligt alweer een decennium achter ons. Je redenering klopt ook niet: al voordat mysql_fetch_assoc wordt aangeroepen, zit de hele resultset in het geheugen van de webserver (of in het geheugen van de dbserver bij een unbuffered query).
Zal best, maar als je appserver onderuit gaat omdat je koste wat 't kost je code 'overzichtelijk' moet houden doe je echt iets fout. En met een fatsoenlijke template engine kun je prima je code en layout gescheiden houden zonder eerst volledige query results in 't geheugen te moeten laden.quote:Veel ontwikkelaars vinden het overzichtelijker om de code en de opmaak van elkaar te scheiden, en met een echo en een mysql_fetch_assoc in dezelfde loop gebeurt dat niet.
Beide zaken zijn met template engines prima te combineren. Jezelf aanleren alles eerst in 't geheugen te laden en er daarna wat mee te gaan doen is gewoon onverstandig.quote:Op dinsdag 6 september 2011 15:05 schreef GlowMouse het volgende:
Leesvoer: http://gathering.tweakers.net/forum/list_messages/1105254
Nog meer: http://www.ukuug.org/events/linux2002/papers/html/php/#section_2
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Hoe geef je je data aan je template engine door zonder het in het geheugen te laden dan?quote:
Beide zaken zijn met template engines prima te combineren.
Weg te schrijven op de HDD en deze haalt de template engine weer op en zal deze echoen?quote:Op dinsdag 6 september 2011 15:16 schreef Tijn het volgende:
[..]
Hoe geef je je data aan je template engine door zonder het in het geheugen te laden dan?
Als jij twee queries uitvoert op MySQL dan wordt er twee keer geheugen gealloceerd voor de resultset.quote:
[..]
Het is gewoon niet waar dat die hele resultset per definitie al in 't geheugen zit. Databaseservers zijn daar veel slimmer in. Als 2 queries dezelfde table benaderen hoeft deze niet 2 keer volledig in 't geheugen te zitten.
Het is wel waar dat wanneer je zelf een array vult, er meer geheugen nodig is om die op te slaan omdat het opslaan minder efficiënt gebeurt.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Door de template gewoon iedere keer de row te voeren in plaats van de hele resultset? Zelf doe ik al tijden niks meer met PHP maar in Java met bijvoorbeeld Spring of JSF is het prima mogelijk om data en layout volledig te scheiden maar wel een pagina per row op te bouwen.quote:
Hoe geef je je data aan je template engine door zonder het in het geheugen te laden dan?
Natuurlijk is het voor een hobbyist die z'n eigen CMSje bouwt geen groot issue, maar jezelf aanleren alles eerst in geheugen te laden is m.i. niet de juiste weg.
Ik weet niet hoe MySQL er mee omgaat maar in MSSQL gaat 'ie met 2 parallelle queries de intersectie van de data maar 1 keer in 't geheugen houden. Je hebt uiteindelijk eigenlijk alleen de rowids van de desbetreffende tables maar nodig, de rest van de data kun je aan de hand daarvan op de cursor doorgeven.quote:
Als jij twee queries uitvoert op MySQL dan wordt er twee keer geheugen gealloceerd voor de resultset.
Het is wel waar dat wanneer je zelf een array vult, er meer geheugen nodig is om die op te slaan omdat het opslaan minder efficiënt gebeurt.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Ik geloof er helemaal niks van, dan zou MSSQL eerst moeten bepalen of resultsets wel gelijk zijn. Dat is met het oog op MVCC vrij inefficient.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Maar je template engine moet al die data toch gevoerd krijgen voordat 'ie kan gaan beginnen met weergeven ervan? Wanneer je 'em de tweede row voert, waar slaat 'ie de eerste dan op als dat niet in het geheugen is?quote:
[..]
Door de template gewoon iedere keer de row te voeren in plaats van de hele resultset?
Hij kan prima een row renderen, net zoals je dat "met de hand" doet.quote:
Maar je template engine moet al die data toch gevoerd krijgen voordat 'ie kan gaan beginnen met weergeven ervan? Wanneer je 'em de tweede row voert, waar slaat 'ie de eerste dan op als dat niet in het geheugen is?
Als een bepaalde tabel veel benaderd wordt gaat 'ie data cachen. Als beide resultsets de row behorende bij rowid X benaderen wordt die data gewoon via een lookup beschikbaar gemaakt. Als je naar een query explain kijkt zie je dat 'ie vaak joins e.d. eerst afhandelt, en pas daarna de data er bij gaat zoeken. Die data komt dan of van disk, of uit de cache. Zowel MSSQL als Oracle doen dat. Of MySQL dat ook doet weet ik niet, maar daar hoef ik gelukkig niet mee te werken.quote:
Ik geloof er helemaal niks van, dan zou MSSQL eerst moeten bepalen of resultsets wel gelijk zijn. Dat is met het oog op MVCC vrij inefficient.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Raar verhaal, bij een query met een aggregated functie heb je het niet meer over rows in een tabel tenzij je de resultset als tabel beschouwt en dan de overhead wilt van het testen op gelijkheid. En heb je dan elke keer een roundtrip als je een rij ophaalt?
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Da's een ander verhaal. Ik zei in het begin al dat dit een issue is bij grote resultsets. Nu hebben we het bovendien over randzaken. Punt is dat het m.i. verkeerd is jezelf aan te leren iedere keer eerst alles in geheugen te lezen omdat het in veel gevallen relatief inefficient is. Dat je het doet op plekken waar het niet inefficient is, of soms juist efficienter; prima. Het gaat mij puur om wat een beginner zichzelf aanleert. Of in ieder geval dat die beginner weet waar hij mee bezig is.quote:
Raar verhaal, bij een query met een aggregated functie heb je het niet meer over rows in een tabel tenzij je de resultset als tabel beschouwt en dan de overhead wilt van het testen op gelijkheid. En heb je dan elke keer een roundtrip als je een rij ophaalt?
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Kan iemand me helpen met deze formule:
De weging wordt bij elkaar opgeteld en maakt 4.
6,5 keer 1 is 6,5 en 7 keer 3 is 21 en wordt bij elkaar 27,5
nu moet het totaal gedeeld worden door de weging en dan komt het uiteindelijke cijfer eruit. Ik hoop dat jullie met nog snappen.
Ik heb met een mysql query dit gedaan maar geeft niet het goeie antwoord.
AAH IK WORD GEK!
| 1 2 3 4 5 6 | cijfer | weging | totaal 6,5 1 6,5 7,0 3 21 totaal: 4 27,5 totaal / weging = uiteindelijk cijfer |
De weging wordt bij elkaar opgeteld en maakt 4.
6,5 keer 1 is 6,5 en 7 keer 3 is 21 en wordt bij elkaar 27,5
nu moet het totaal gedeeld worden door de weging en dan komt het uiteindelijke cijfer eruit. Ik hoop dat jullie met nog snappen.
Ik heb met een mysql query dit gedaan maar geeft niet het goeie antwoord.
| 1 2 3 4 | $query = mysql_query("SELECT SUM(weging) as wtotal, SUM(cijfer * weging) as itotaal, SUM(weging / itotaal) as totaal FROM cijfers"); |
AAH IK WORD GEK!
Lekker happen
En de laatste SUM weglaten.quote:
Je moet ook wtotal gebruiken en niet weging.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
.
probeer een file te unzippen maar werkt niet...krijg ook geen foutmelding wat er fout zou kunnen gaan. Path is goed, daar geeft ie wel een foutmelding op als de niet komt
| 1 2 3 4 5 6 7 | <?php require_once("pclzip.lib.php"); $zip = new PclZip("uploads/".$filename); if($zip->extract() == 0) die("Error : " . $zip->errorInfo(true)); ?> |
Hoever ben je zelf al gekomen met debuggen? Error_reporting(E_ALL); al keertje aangepleurd?quote:
probeer een file te unzippen maar werkt niet...krijg ook geen foutmelding wat er fout zou kunnen gaan. Path is goed, daar geeft ie wel een foutmelding op als de niet komt
[ code verwijderd ]
