I dette særtema ser vi på, hvordan cloud og AI bliver fundamentet for virksomhedernes digitale forretning, og hvordan de nye muligheder for automatisering og forretningsværdi kan udnyttes uden at miste overblik, sikkerhed og menneskelig kontrol.
ja, det var vist en klassisk fejl40... Har vist siddet her for længe..
Drop et svar jakoba...
Synes godt om
Slettet bruger
28. september 2004 - 23:43#7
Du er ikke den eneste. Jeg kan da se et par tastefejl mere i mine indlæg, som jeg ikke burde have lavet. Og bromer var også lidt underholdende tidligere idag.
Jeg tror at sandbox mener at det er mere læseligt. Det virker også underligt at køretiden ikke minder meget om hinanden.. så er foreach dårligt impelmenteret...
Hehe ... nu må vi have et par forklaringer mere. Hvorfor er det mærkeligt, foreach er langsommere - og hvorfor skulle det betyde dårlig implementering? På mig virkede det helt urealistisk, at foreach skulle være ligeså hurtig - eller hurtigere ... derfor testede jeg. I en foreach-løkke bruges jo ikke en alm. incrementor - det underliggende API tager fat i array'et på en helt anden måde.
Jeg skal ikke kunne udtale mig om hvordan API'et tager hånd om et array på. Det er heller ikke mærkeligt at foreach er langsommere.. jeg synes bare en faktor 2 er rigtig meget. Der er for det første ikke forskel på hvordan $a bliver opbygget i de to eksempler, hvilket tyder på at foreach er mere end er faktor 2 langsommere.
Det undrer mig at API'et ikke laver nogle undersøgelser omkring array'et opbygning og derefter vælger den hurtigste måde at udføre foreach på.
Ja, sådan kan man jo så undre sig over, der er så stor forskel på, hvad der får folk til at undre sig. Jeg undrede mig faktisk over, forskellen trods alt ikke var større *LoooL*
Nej, forskellen er cirka en faktor 2. Jeg har ikke snakket om 'mere end to'. Når jeg fortæller dig, at forskellen på en for- og en foreach-løkke er en faktor 2, har jeg naturligvis ikke talt andet end afviklingen af løkkerne med ;o)
Okay.. men det var jo oplagt at tro at du havde :) Men jeg synes stadig ikke at køretiden burde afvige med mere end en konstant faktor, hvilken jo så ville blive uden betydning når ens array var stort nok.
Du nævnte at API behandlede arryet meget forskelligt. Har du det fra kildekoden eller er det beskrevet et sted i manualen?
Synes godt om
Slettet bruger
29. september 2004 - 23:02#15
Det har nok noget at gøre med, at når man bruger foreach bliver arrayindholdet hele tiden kopieret over i de andre variable. Det er også derfor, man ikke kan ændre i et array på denne måde:
foreach($array as $value){ $value++; }
Så kan man jo gå igang med at diskutere forskellige typer performance: Er det vigtigst, at applikationen er effektiv, eller er det vigtigere, at programmøren er? Og ved hvilken grad af programkompleksitet skal man droppe at optimere programmet, for at det stadig er til at gennemskue, hvad der foregår? (Nej, så kompleks er en for-løkke heller ikke, det er mere princippet.)
Forresten skulle den passende løkke nummer 2.2 i oleboles eksempel nok have set således ud:
sandbox >> Det er præcis, hvad der får det til at se logisk ud, at en foreach er langsommere.
Jeg er helt enig i dine principielle betragtninger om overskuelighed og performance - men når koden er så enkel som her, vil jeg afgjort mene, der bør optimeres for hastighed ;o)
Ja, du har helt ret i, at jeg faktisk testede forkert ... gav foreach et 'unfair handicap'. Naturligvis burde min foreach-løkke have udført præcis samme stykke arbejde. My bad ... selvom det nu ikke piller nævneværdigt ved hastigheden :) /mvh
Synes godt om
Slettet bruger
13. oktober 2004 - 15:32#17
Grunden til at jeg i så høj grad foretrækker foreach til at gennemløbe arrays er nok, at jeg meget ofte bruger arrays med tekstbaserede indekser - og der kan en almindelig for-løkke ikke bruges til meget.
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.