Hvorfor skriver du "mindst en måned frem" i stedet for det, du ønsker? Du kan vel ikke bruge en, der viser 14 år og 312 dage ud i fremtiden ... eller? *o)
Anyway, her er en funktion, som skriver en SELECT ud, som rækker frem til samme dag som idag - næste måned:
Scriptet virker for december, men hvor den skulle skrive januar skriver den 1. december 1969 i stedet for 1. januar 2013, men det er lige det jeg soeger hvis den kunne komme til at skrive rigtigt for januar
"Scriptet virker for december, men hvor den skulle skrive januar skriver den 1. december 1969 i stedet for 1. januar 2013, men det er lige det jeg soeger hvis den kunne komme til at skrive rigtigt for januar"
Det giver da ikke mening i forhold til, hvad du spørger om. Du beder om en SELECT, som skriver en måned ud fra dags dato. Hvad er det, du ønsker?
@T4NK32: Ja, noget i den retning, er jo det allerførste, man kommer til at tænke på. Lige indtil man kommer til at tænke sig om og opdager, at man opretter 4 (fire) nye date objekter for hvert gennemløb af løkken.
Hvor du kan nøjes med 3 opretter din kode 120 - dvs. 117 unødvendige instantieringer af date objektet. Så kan det vist ikke skrives mere ineffektivt =)
@techboy992: Nu har jeg læst #7 igen, men det passer ikke, hvad du skriver. Det script, jeg lagde i #3 skriver fint '01. januar 2013'.
Jeg ved ikke, hvad du har gjort for at få det til at skrive '1. december 1969', men det er i hvertfald ikke min kode, der gør det =)
Jeg kan se i denne tråd, at du roder lidt rundt i PHP's tidsformatering (og det kbiber såmænd også for de andre i tråden at se det), så mon ikke, det er noget lignende, du gør, når du tester koden ovenfor?
Synes godt om
Slettet bruger
15. december 2012 - 21:21#17
#15 - Det kan der jo være noget om : (
Jeg har lige prøvet at køre min version igennem 10.000 gange - Det tog 14 sekunder, svarende til 1,4 millisekunder pr. sidevisning.
Din version (som, ganske rigtigt fungerer helt fint som den er) - Tager 13 sekunder for 100.000 gennemkørsler!
Din kode er altså cirka 10 gange hurtigere (dog uden ugedagsnavne)
Til gengæld er den ekstremt indviklet og nærmest umulig at læse. - Det anser jeg for vigtigere sålænge siden ikke har millioner af hits pr dag..
OK, det er en efterrationalisering (og jeg blev overrasket). Men alligevel... Overoptimering ?
Synes godt om
Slettet bruger
15. december 2012 - 21:27#18
#14 - timestampet i databasen har ikke noget at gøre med den dato brugeren ser! - det kommer fra value i den option brugeren vælger.
Men da det er PHP's tidsformat (antal sekunder siden 1. januar 1970) - kan det jo formateres som du vil når formen kommer tilbage til serveren.
"Til gengæld er den ekstremt indviklet og nærmest umulig at læse"
Det må komme an på, hvad man er vandt til at sidde med af koder. Er ovenstående 'ekstremt indviklet og uforståelig', skal der godt nok ikke meget til at forvirre dig! Men det hænger vel sammen med, at det overhovedet kan overraske dig, at din kode performer så skidt.
Til dit spørgsmål om overoptimering: Ikke spor! Det er bare fornuftig kode, der er tænkt en smule over =)
Tankegangen bag min kode er fuldstændig elementær. Den hænger nøje sammen med, at det første, du lærer, når du begynder med løkker: Skriv aldrig:
for ($i=0; $i<count($myArray); $i++)
- men:
for ($i=0,$j=count($myArray); $i<$j; $i++)
- netop for at undgå at slå antallet af array'ets elementer op ved hvert gennemløb. Det performer elendigt - og det er end ikke en beregning/instantiering, men 'bare' en aflæsning af en property på array'et.
Det er præcis samme 'programmatiske børnelærdom', der ligger bag at undgå alle de unødige instantieringer af date objektet
Synes godt om
Slettet bruger
15. december 2012 - 23:02#20
Har De det bedre nu, hvor De igen, igen har overdænget mig med lort, Lektor Blomme ? - den selvforherligende, stoltserende stil er voldsomt (og helt unødvendigt) provokerende!
Jeg fastholder at din løsning, som den foreligger, er komplet ulæselig. - det vil tage enhver (bortset fra dig selv de næste 3 dage) adskillige minutter at gennemskue/ændre.
Overoptimering: 1.4 millisekunder er ikke et "performance problem" for andre end google.com - Slut!
*LoL* 'Lektor Blomme' ... Herregud, hvor tager du dog ikke Stalin, Hitler og Breivik med i din offerdyrkelse? :D
Der er ingen andre end dig, der sludrer om 1.4 millisekund. For mig handler det om, at holde en god og effektiv kodestil. Jeg lever af at udvikle, og så har man ikke tid til at sidde og tage tid på hver eneste linje kode, man skriver. Derfor overholder man som professionel gode, gennemprøvede grundregler, så man er sikker, når det virkelig gælder.
Du må fastholde, hvad som helst - men jeg kender rigtig mange, der absolut ingen problemer har med at læse den kode. Du har næppe indsigt i, hvad 'enhver' kan læse - endsige hvad jeg kan læse om tre dage. Hold dig til at afgøre, hvad du selv kan finde ud af, please *o)
Synes godt om
Slettet bruger
16. december 2012 - 00:01#22
Jeg har på fornemmelsen af at du mere lever for end af at udvikle.
Jeg har selv levet af det i 25 år, og kan (igen) fortælle dig at læs- og vedligeholdbar kode er meget vigtigere end minimale performance gevinster.
- Stalin, Hitler og Breivik er/var massemordere, Lektor Blomme bare en sølle lille selvfed sadist.
Nå, dét er forskellen ... jaja, it takes one to know one =)
Dine 'fornemmelser' vil jeg gerne blande mig uden om, og hvad dine erfaringer angår, så er det forlængst gået op for mig, du har besvær med at læse ovennævnte kode.
Det ændrer ikke ved det faktum, at det er hel elementær programmeringslærdom at foretage sig så lidt som muligt i et loop. Det står på første linje i forordet til enhver lærebog i ethvert sprog!
Derudover kan der sagtens være en faktor 10 til forskel på RAM-forbruget ved to fremgangsmåder - selvom der kun er få procents forskel i afviklingstiden. Det handler om garbage collection, og her trækker objekt instantiering ofte tænder ud.
Jeg lukker det her spoergsmaal det er loebet af sporet
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.