Fick lite problem med att ett skript försökte allokera för mycket minne.
Skriptet lyckades processa ca 6000 av 30000 poster innan det blev för mycket minne.
Så antingen får jag dela upp så att skriptet bara tar en liten bunt i taget eller optimera mitt skript.
Det jag funderade över är om det har någon betydelse var man deklarerar sina variabler.
Dvs är det någon skillnad på
for($i=0; $i < 10000; $i++)
{
$r = $i;
}
och
$r = 0;
for($i=0; $i < 10000; $i++)
{
$r = $i;
}
Kommer de två looparna att förbruka lika mycket minne?
Har det någon betydelse ifall man deklarerar $r utanför for-loopen?
Kommer första loopen att skapa 10000 olika variabler och därmed förbruka mer minne?
Jag har svårt att tro att det skulle vara någon skillnad. Problemet ligger nog någon annanstans. Vad är det du processar? Bygger du upp stora arrayer t.ex?
Jag har ett svagt minne av att det ska gå något fortare att räkna neråt, istället för upp.
$i--
Njaaaaa... Du tänker nog på en helt annan sak. När man satt och gjorde riktigt täta loopar i C och bara ville loopa x gånger utan att bry sig om loop-räknarens värde så kunde man skriva...
i = 42;
do{
}while (--i);
Konceptet true/false finns inte i C, utan allt som inte är 0 räknas som true. Alltså fortsätter loopen att snurra till resultatet av --i blir 0. Detta att jämföra med en vanlig for-loop där man behöver en instruktion till (jämförelse-operatorn) för att få ut samma resultat. Knappast applicerbart på PHP, och knappt ens applicerbart på dagens CPUer pga av cache-arkitekturen och tiden minnes-åtkomst. (Det som finns inuti loopen kan antas slöa ner mer än det overhead som kommer från kontrollkoden till loopen.)
Hulken, jag tror att ditt fel beror på att result set'et från databasen är för stort för minnet. Hur ser databas-koden ut? Säg inte att (shrug) du kör en databasfråga i varje loop-runda? För övrigt, det är fullt möjligt att det du vill göra går att göra snabbare och bättre enbart med SQL utan att man behöver loopa gnom datat med PHP.
130 ms totalt · 3 externa anrop · v20260731065814-full.4bcf49fe
