tijd voor recursieve functie

[Verwijderd]

Ik heb een recursieve functie geschreven die nogal wat tijd nodig heeft voordat ie true wordt. Hij encrypt namelijk wat, maar dat kan bij lange stukken gauw een half uur duren...

Het is geen mogelijkheid om het in lappen te verdelen en apart uit te voeren, omdat hij dan niet meer te decoden is.

Nu is dat allemaal niet zo erg, maar mijn php loopt (logisch) vast wanneer ie na een paar sec nog niet opgelost is, vanwege de mogelijkheid dat het een memory leak is en dat het nooit true zal worden.

Maar dat ie ooit true wordt weet ik zeker, het kan alleen een tijdje duren. Hoe kan ik er nu voor zorgen dat PHP weet dat ie z'n gang mag gaan en m'n memory mag opslokken om z'n taak maar te doen?

[D2k]

commandline proberen?
of je php.ini settings veranderen?

[Verwijderd]

Ik heb in m'n php.ini memory_limit = 8M verandert in 256M, maar hij neemt geen seconde langer de tijd voor het script, terwijl het 32 keer zoveel is... ik denk dus niet dat dat werkt, ik denk eerder dat ik iets moet veranderen in m'n windows instellingen...

[ACM]

En een efficienter algoritme schrijven
De 1024-bits encryptie van SSH2 kan data met 300KB/sec encrypten op een celeron 300...
(geloof ik wel dat SSH stiekem vals speelt en niet de 1024bits encryptie gebruikt bij de transmissie, magoed, nog steeds iets als triple-des)

mem-limit verhogen betekend niet 'gebruik meer geheugen', maar exact wat de naam zegt.

[Verwijderd]

Op zondag 14 juli 2002 15:59 schreef ACM het volgende:
En een efficienter algoritme schrijven
De 1024-bits encryptie van SSH2 kan data met 300KB/sec encrypten op een celeron 300...
(geloof ik wel dat SSH stiekem vals speelt en niet de 1024bits encryptie gebruikt bij de transmissie, magoed, nog steeds iets als triple-des)

mem-limit verhogen betekend niet 'gebruik meer geheugen', maar exact wat de naam zegt.

Tsjah, dat moet dan maar, want ik heb een AMD 1500 XP+ met 512 intern, dus dat lijkt me meer dan genoeg...

Wat zijn de dingen waar je op moet letten om zoiets te optimaliseren, want mijn algoritme maakt niet echt gebruik van hele spectucalaire dingen...

[Alarmnummer]

Het probleem zit hem in het feit dat je een recursieve functie gebruikt. Iedere keer als je een functie aanroept, dan moet er op de stack ruimte gereserveerd worden (dat kan nogal wat zijn ivm variable declaraties ed). Als je 10.000 aanroepen diep zit, kan je zelf wel nagaan dat je een enorme hoeveelheid geheugen kwijt bent. Meestal schrijf ik mijn funcities ook recursief omdat ze heel eenvoudig zijn, maar als ik weet dat het high performance moet zijn, dan ga ik over naar iteratief? (weet niet precies de naam daarvoor, iteraties lijken me eerder horen bij iteraten over een verzameling ofzo).

[ACM]

Op zondag 14 juli 2002 16:02 schreef dannydude het volgende:
Tsjah, dat moet dan maar, want ik heb een AMD 1500 XP+ met 512 intern, dus dat lijkt me meer dan genoeg...

Dat zeg je wel heel teleurgesteld
Je algoritme, zeker dat soort dingen, hoort altijd al minstens 'een beetje geoptimaliseerd' te zijn.

Wat zijn de dingen waar je op moet letten om zoiets te optimaliseren, want mijn algoritme maakt niet echt gebruik van hele spectucalaire dingen...

Als een loop 1 commando korter _kan_ moet je dat ook doen.
Vooral de stukken code die veel uitgevoerd worden (de loops enzo) bekijken.
Profile hoelang stukken code duren en zoek uit waarom.
Gebruik zoveel mogelijk de ingebouwde functies van php.
Doe geen calls naar niet bestaande vars en al helemaal niet naar niet bestaande array-items.

[Verwijderd]

Op zondag 14 juli 2002 16:04 schreef ACM het volgende:

[..]

Dat zeg je wel heel teleurgesteld
Je algoritme, zeker dat soort dingen, hoort altijd al minstens 'een beetje geoptimaliseerd' te zijn.
[..]

Als een loop 1 commando korter _kan_ moet je dat ook doen.
Vooral de stukken code die veel uitgevoerd worden (de loops enzo) bekijken.
Profile hoelang stukken code duren en zoek uit waarom.
Gebruik zoveel mogelijk de ingebouwde functies van php.
Doe geen calls naar niet bestaande vars en al helemaal niet naar niet bestaande array-items.

Daar voldoet ie wel al behoorlijk aan, maar ik zal dan maar es kijken of ik hem ook iteratief kan bouwen...

[Verwijderd]

Misschien is de eerste vraag die je je kunt stellen:
is je algorithme niet efficient genoeg, of is je implementatie niet efficient genoeg?

Kan je een worst-case tijd geven voor je algorithme in orde van de input lengte? En in hoeverre komt dit overeen met de werkelijkheid, dwz zou een efficientere implementatie echt nut hebben?

In het eerste geval zou je naar een efficienter algoritme kunnen zoeken, in het tweede geval kan je wellicht met profiling, etc kijken of je bepaalde gedeelten code nog wat kan "inkorten".

[xoror]

Op zondag 14 juli 2002 15:59 schreef ACM het volgende:
En een efficienter algoritme schrijven
De 1024-bits encryptie van SSH2 kan data met 300KB/sec encrypten op een celeron 300...
(geloof ik wel dat SSH stiekem vals speelt en niet de 1024bits encryptie gebruikt bij de transmissie, magoed, nog steeds iets als triple-des)

mem-limit verhogen betekend niet 'gebruik meer geheugen', maar exact wat de naam zegt.

ssh werkt met een hybride systeem (zoals veel andere systemen). mem gebruikt een asymetrisch algo om een symetrische key uit te wisselen. deze symetrische key wordt voor de daadwerkelijke 'encryptie van de lijn' gebruikt.

[Verwijderd]

Eerlijk gezegd vraag ik me af wat de toepassing is voor het encrypten als het zo lang duurt. Ik neem aan dat er niet een real-time aktie op moet worden genomen, want een gebruiker gaat niet zolang wachten totdat een pagina terug komt.

Je kan evt. je applicatie extern laten draaien via bijv. het gebruik van exec(). Je kan dan door gaan met je PHP zonder te wachten op een resultaat. Zelfs als je PHP proces stopt loopt het externe proces door. Zo kan je een .vbs bestandje laten runnen wat uiteindelijk je encryptie doet en opslaat.

Je voporkeur zou natuurlijk uit moeten gaan naar een meer efficient algoritme zodat je ook binnen PHP eventuele problemen tijdedns encrytie kan melden.

HTH