Nested for-loops

[michiel3]

Ik heb een vrij rekenintensieve app geschreven die gebruik maakt van 4 geneste for-loops. Je zou het ongeveer zo kunnen weergeven:

int a,b,c,d;
for(a = 0; a < 52; a++){
    for(b = 0; b < 36; b++){
        for(c = 0; c < 36; c++){
            for(d = 0; d < 36; d++){
                // Handle code
                // Maak string van de indices met behulp van [NSString stringWithFormat:@"..."]
                // SHA1-hash maken van de string
                // Controle uitvoeren in if-statement, true: loops stoppen, false: go on
            }
        }
    }
}

De eerste loop loopt dus van 0 tot 52 de rest van 0 tot 36. Het probleem is: de Simulator handelt deze taak zeer snel af, maar de iPhone zelf (iPhone 3GS) zeer traag. Is de snelheid van de Simulator niet gelijk aan die van de echte iPhone? Uiteraard maakt de Simulator geen gebruik van GSM enz., maar ook al zet ik m'n iPhone in vliegtuigmodus: nog steeds traag.

Uiteraard heeft het er mee te maken wat er binnen in de for wordt uitgevoerd: een aantal berekeningen met de indexes van de lopende fors. Hieruit wordt een SHA1-hash berekend.

De methode draait in een aparte thread, om er voor te zorgen dat de UI blijft werken. Dit leverde wel snelheidswinst op.

P.S. ik heb al veel optimalisaties doorgevoerd. Ik autorelease alles dat binnen de for wordt aangemaakt en na één for-cycle niet meer nodig is. Daarnaast heb ik alle index defines buiten de for. De lengtes van de loops heb ik ook allemaal hardcoded en dus geen method call in de for signature, zoals: [anArray length].

Vraag: waarom kan de Simulator de loops 25 minuten eerder afronden dan de iPhone zelf? Ik neem aan dat de Simulator beperkt wordt in zijn snelheid en niet volledig gebruik maakt van de processor in m'n MacBook?

---

Laatst gewijzigd door michiel3; 16-08-09 om 23:08. Reden: Verduidelijking

[Nikooos]

Volgens mij gebruikt de simulator wel volledig gebruik van het geheugen en de processor van je macbook. Tenminste, dat is mijn 'gevoel'. Ik merk het ook met heel veel dingen dat het op de macbook veel sneller gaat dan op de iPhone zelf.

Ik kan dit niet onderbouwen met bewijsmateriaal, maar dat is wel het idee dat ik heb.

__________________
Het grootste voetbalforum van Nederland

[SkyTrix]

Ik kan je met zekerheid zeggen dat de Simulator volledige resources gebruikt. Daarom dat je dan ook altijd moet testen op een echt device. De code die je uitgevoerd wil zien is blijkbaar veel te intensief voor de processor en het beschikbaar geheugen op het device.

[Whacko]

De simulator gebruikt inderdaad gewoon de volledige resources van je Macbook.

Ik zou eens gaan kijken wat er precies de vertragende factor is in je berekening. De for loops kunnen het probleem niet zijn, dus zou ik in het diepste niveau eens wat berekeningen uitschakelen totdat je de bottleneck hebt gevonden, en die eventueel optimaliseren. Ik weet natuurlijk niet je precieze code, maar string operaties zijn redelijk zwaar denk ik, en het berekenen van een SHA-1 hash ook wel. Die eerste zou je misschien kunnen versnellen door geen strings te gebruiken maar character arrays, en dan op het laatst converteren naar string.

__________________
Software Engineer
iPhone Developer

[michiel3]

Jammer dat de Simulator qua snelheid niet de snelheden van de iPhone nabootst en ook het geheugen.

Oorspronkelijk geplaatst door Whacko

Ik zou eens gaan kijken wat er precies de vertragende factor is in je berekening. De for loops kunnen het probleem niet zijn, dus zou ik in het diepste niveau eens wat berekeningen uitschakelen totdat je de bottleneck hebt gevonden, en die eventueel optimaliseren. Ik weet natuurlijk niet je precieze code, maar string operaties zijn redelijk zwaar denk ik, en het berekenen van een SHA-1 hash ook wel. Die eerste zou je misschien kunnen versnellen door geen strings te gebruiken maar character arrays, en dan op het laatst converteren naar string.

Geheugen is in ieder geval niet het probleem. Bedankt voor de tip, ik ga proberen uit te zoeken wat het zware gedeelte is. Vermoedelijk die string mutaties en de SHA-1 hash dus. Mocht het nodig zijn, dan probeer ik je voorstel van de character array! Dankjewel!

[Matisse]

Ik ben eigenlijk wel benieuwd waarvoor die code wordt gebruikt... SHA1 hash berekenen van 2426112 strings lijkt me toch wel vrij intensief voor een iPhone. Je kan trouwens met Instruments perfect zien waar je app de meeste tijd doorbrengt en daar je optimalisaties concentreren. Mss kan je een efficienter SHA1 algoritme gebruiken ofzo.

[Nikooos]

Oorspronkelijk geplaatst door psychonikeo

Volgens mij gebruikt de simulator wel volledig gebruik van het geheugen en de processor van je macbook. Tenminste, dat is mijn 'gevoel'. Ik merk het ook met heel veel dingen dat het op de macbook veel sneller gaat dan op de iPhone zelf.

Ik kan dit niet onderbouwen met bewijsmateriaal, maar dat is wel het idee dat ik heb.

Hier nog even op terugkomend.. Even een stukje quoten van de apple developers site:

Testing on the iPhone Simulator vs. Testing on iPhone or iPod touch
With the iPhone Simulator, you can quickly prototype your ideas, debug memory leaks, simulate memory warnings, and get a good feel for how your app is going to work. However, since the iPhone Simulator simulates APIs, not hardware, the iPhone Simulator is not a replacement for testing on an actual device.
When you run your application in the iPhone Simulator, you're running a Mac OS X, 32-bit, Intel-architecture application, and it's running at the native speed of your Mac. Conversely, your iPhone has features your Mac doesn't—like GPS and an accelerometer—and the iPhone Simulator might provide different information from what you'd get on a device (for example, Core Location always returns a location in Cupertino, CA). In addition, if you only test on the iPhone Simulator, you might not get the true behavior of your application, such as video frame rate, memory capacity, network access and access to the camera.