Skillnad mellan att optimera android och iOS??

Det beror ju helt på vad för optimering som menas. Om man själv gör ett program så gäller det ju att välja bra algoritmer beroende på vad man ska lösa för problem eller vad programmet ska göra. Gör man en egen sorteringsalgoritm där man jämför varje värde onödigt många gånger så är det säkert något man kan optimera och det har ju inget att göra med om det är Android eller iOS.

Optimera vad?

frågan är fortfarande otydlig tycker jag

optimering i Eclipse eller annan utvecklingsmiljö är densamma, vissa har inbyggda linters eller som plugin som kan hjälpa dig att i vissa fall optimera

generell optimering handlar ju mer om att utnyttja resurser så liten tid som möjligt etc, coarse location finns(eller fanns förr iaf) i android om du inte är intresserad av nogrannare position, men jag vet inte om det är mer optimerat, sånt får man nästan kolla upp i specifika fall.

Kort och gott: optimering av kod har egentligen ingenting med ett IDE att göra (det kan möjligtvis vara lättare att navigera runt i ett projekt med ett bra utvecklingsverktyg, vilket i sin tur kan resultera i bättre kod).

Några prestanda relaterade saker jag märkt med Android på den minimala tid jag än lyckats lägga på min "Dalvik benchmark" som jag håller på att skriva är

• Det är dyrt att skapa många kortlivade objekt, mycket dyrare än vad det blir i samma program körandes på en "vanlig" JVM. Det skiljer en till två tiopotenser mellan OpenJDK7 och Dalvik på Android 4.0. Detta är inte så svårt att förklara, Dalvik är optimerad till att vara väldigt aggresiv med sin skräpsammling då mobila enheter typiskt har ganska begränsat med RAM jämfört med de server-maskiner som typiskt kör JVM:erm med "hotspot" optimering.

• Ren aritmetik (beräkningar) är däremot i princip lika snabbt under Dalvik som under OpenJDK7. Och OpenJDK är snabb, helt i nivå med kod skrivet i C/C++.

• Hopp orsakade av jämförelser (if-satser) verkar också vara effektivt, d.v.s i nivå med OpenJDK

• Primitiver för lås och atomära variabler är inte fullt lika effektiva under Dalvik som under OpenJDK7, men helst ska man undvika alla sådana operation i alla fall om man vill att programmet ska skala väl över flera CPU-kärnor

Det jag har kvar att skriva är tester för kostnad av funktionsanrop, både rekursiva och icke-rekursiva anrop. Här kan jag tänka mig att en "hotspot" JVM har en del fördel, men vem vet...

[QUOTE=Yoshman;13370645]Några prestanda relaterade saker jag märkt med Android på den minimala tid jag än lyckats lägga på min "Dalvik benchmark" som jag håller på att skriva är

• Det är dyrt att skapa många kortlivade objekt, mycket dyrare än vad det blir i samma program körandes på en "vanlig" JVM. Det skiljer en till två tiopotenser mellan OpenJDK7 och Dalvik på Android 4.0. Detta är inte så svårt att förklara, Dalvik är optimerad till att vara väldigt aggresiv med sin skräpsammling då mobila enheter typiskt har ganska begränsat med RAM jämfört med de server-maskiner som typiskt kör JVM:erm med "hotspot" optimering.

• Ren aritmetik (beräkningar) är däremot i princip lika snabbt under Dalvik som under OpenJDK7. Och OpenJDK är snabb, helt i nivå med kod skrivet i C/C++.

• Hopp orsakade av jämförelser (if-satser) verkar också vara effektivt, d.v.s i nivå med OpenJDK

• Primitiver för lås och atomära variabler är inte fullt lika effektiva under Dalvik som under OpenJDK7, men helst ska man undvika alla sådana operation i alla fall om man vill att programmet ska skala väl över flera CPU-kärnor

Det jag har kvar att skriva är tester för kostnad av funktionsanrop, både rekursiva och icke-rekursiva anrop. Här kan jag tänka mig att en "hotspot" JVM har en del fördel, men vem vet...[/QUOTE]

Angående funktionsanrop. Detta är saxat från "Apress - Beginning Android Development"

"Method calls have a larger associated cost in Dalvik than in other VMs. Use static methods if you can, as those perform best. Static methods are generally regarded as evil, much like static variables, as they promote bad design. So try to keep your design as clean as possible. You should maybe avoid getters and setters as well. Direct field access is about three times faster than method invocations without the JIT, and about seven times faster with the JIT. Again, think of your design before removing all your getters and setters, though."

Kanske inte så förvånande om man tänker lite på det. Dels kan en hotspot JVM optimera bort vissa funktionsanrop alt. inse att det är alltid underliggande typ som anropas och man kan ersätta det indirekta anropet via funktionspekaren associerad med metoden för underliggande typ med ett direkt anrop (vilket är exakt vad man får vid hopp till en statisk metod).

En annan anledning är nog att Dalvik, till skillnad från "vanliga" Java och även CLR (virtuella maskinen i .Net), är en registerbaserad JVM medan de andra är stackbaserade. Att göra funktionsanrop i en registerbaserad VM kräver att man sparar "callee save" register och den anropade funktionen måste spara "caller save" register, något som kostar extra instruktioner och därmed tid. I en stackbaserad JVM finns inte det problemet.

Dalvik kör säkert med registerbaserad VM då det bättre återspeglar ARM arkitekturen (och således kräver en mindre avancerad JIT-kompilator, JIT kan dra en del resurser), är egentligen bara x86 som kan hantera en stackbaserad JVM riktigt effektivt (både Intel sedan Pentium M och AMD sedan i alla fall Phenom II har dedikerat kiselyta explicit för vissa instruktioner som jobbar mot stacken).

Har testat detta i min benchmark och föga oväntat ser jag precis det man nämner i "Beginning Android Development". I det test-case jag skapade för min benchmark tar det en faktor 16 så lång tid att köra programmet i Dalvik jämfört med OpenJDK7. Det kvittar om metoden är static eller ej i Dalvik, skillnaden var faktiskt lite större för static metoder (en faktor 17 mot OpenJDK7).

Så det man ska undvika i Dalvik är små korta metoder samt skapa väldigt många kortlivade objekt, för det är väldigt dyrt jämfört med en "vanlig" JVM.

Det var riktigt tråkigt det. Tror du det skulle vara möjligt att optimera Dalvik så den hanterar "ordentlig Java" bättre? ODEX-verktyg borde kunna göra vissa optimeringar tycker jag.

Som jag skrev ovan, Dalvik har andra designkriterier jämfört med "vanliga" Java. Davik är optimerad för interaktiva applikationer som ska köras på relativt svaga inbyggda system (telefoner och pekplattor). "Vanliga" Java är numera väldigt fokuserat på back-end system som typiskt är väldigt CPU-starka system med massor med RAM.

Den andra stora skillnaden är att "vanliga" Java-program typiskt kör väldigt länge så "hotspot" optimeringar är väl värda kostnaden medan Android program måste vara interaktiva direkt och körs typiskt ganska kort tid (CPU-tidsmässigt).

Men jämför man Android och iOS så tycker i alla fall jag att Java med de begränsningar/egenskaper som man får med Dalvik ändå är en rätt mycket trevligare miljö jämfört med ObjC/Cocoa. Är problemet riktigt CPU-begränsat så kan man alltid ta till NDK på Android och använda C eller C++.

Ska kanske tillägga att jag kör jämfört Dalvik/OpenJDK på Atom som nog hanterar den stackbaserade design som "vanlig" Java använder lite mer effektivt än vad en ARM CPU skulle göra. Har kört Dalvik koden även på ARM, relativt prestanda i andra benchmarks så är Dalvik något mer effektivt på ARM i anrops-testet (kanske inte så oväntat då bytekoden i Dalvik verkar rätt ARM centrerad), men det handlar ändå om 15-16 gånger längre körtid på en 1GHz Cortex A9 på Dalvik jämfört med vad Atom på 1.6GHz får på OpenJDK7. I många andra benchmarks så är Atom system definitivt snabbare även i Dalvik men i detta test är det jämt skägg tidsmässigt.

Det andra testet som Dalvik var riktigt uselt jämfört med OpenJDK, skapandet av många temporära objekt, så var Dalvik/Atom-systemet mer än dubbelt så snabb som Dalvik/ARM systemet. Men båda var typ två tiopotenser långsammare än OpenJDK7/Atom.

Kommer göra hela programmet och all källkod för min benchmark tillgänglig här på SweC när den är tillräckligt klar. Är mest ett projekt jag jobbar med nu för att lära mig grunderna i Android-programmering, men var också intresserad att se hur pass bra/dåligt Dalvik är för x86 jämfört med ARM.