C in Android nutzen: Geht's primitiver als Java?

Marco Feltmann · 6. Februar 2013

Moin,

ich habe hier so ein paar Berechnungen, die gern etwas schneller gehen dürften.
Vor Allem im Vergleich mit dem iPhone stinkt Android ganz gewaltig ab.
(0.6ms vs 10.0ms)

Mag sein, dass mein Versuch des Benchmarks nix taugt, da via

Java

new Timestamp(new Date().getTime());

ja immer ordentlich Bewegung auf der VM ist. Nichts desto trotz ist es gefühlt sehr langsam - das will ich so nicht.

Hat jemand einen Tipp oder ein Tutorial, aus dem hervor geht, wie man schnelle C-Funktionen in eine Android-App bekommt?
Da das zu Grunde liegende System außerhalb der VM ja ein Linux ist, muss es auch eine C-Unterstützung geben.
Ich würde die gern nutzen, da die Berechnungen unter allesamt mit Zeigern, Strukturen und primitiven Datentypen durchgeführt werden.
In Android habe ich das Problem, dass alles ein Objekt ist. Das kostet ungemein Zeit.

Bin für jeden Tipp dankbar.

block_ · 6. Februar 2013

Um die Dauer von etwas zu berechnen, würde ich nicht ein Date-Objekt nehmen. Das ist, wie du schon gesagt hast sehr ungenau. Nimm stattdessen

Code

long start = System.nanoTime();
/*
weiterer code
*/
long end = System.nanoTime()

Die Differenz von beiden ergibt ein mehr oder weniger genaues Ergebnis (besser als Date )

Grundsätzlich lässt sich mit Java auch sehr perfomant arbeiten, solange man es richtig macht. Vorher würde ich prüfen ob du auch wirklich alles rausgeholt hast, was irgendwie möglich ist. Wenn du dann immer noch nativen Code einbinden möchtest, solltest du dir das Android NDK mal anschauen. Gibt auch eine Menge Tutorials dazu im Netzt.

block_

Marco Feltmann · 7. Februar 2013

Danke für den Tipp mit der System.nanoTime().

Leider missfällt mir das Ergebnis doch sehr...

Eine Schleife von 10.000 Durchläufen dauert:
iOS Simulator:
0.08 Sekunden
Android Emulator:
7.64 Sekunden

Verzehnfache ich die Durchläufe wirds noch ätzender:
iOS Simulator:
0.84 Sekunden
Android Emulator:
64.17 Sekunden

Der einzelne Durchlauf beträgt im Schnitt:
iOS Simulator:
8µs
Android Emulator:
642µs

Das ist um Faktor 80 langsamer.

Schlimmer wird es bei einer einzelnen Berechnung.
iOS Simulator:
6µs
Android Emulator:
1366µs

Also um mehr als Faktor 200 langsamer.

Natürlich ist C unschlagbar fix und natürlich ist der Simulator schneller sowie der Emulator langsamer als das Endgerät.
(Gut, bei Letzterem und meinem HTC One V bin ich mir nicht sicher.)

Nur wüsste ich nicht, was ich optimieren kann.
Es wird viel mit Sinus, Cosinus, Quadratwurzel und Floor gearbeitet. Also die Klassenmethoden von Math werden ordentlich getriggert.
Weiterhin habe ich keine eigenen Structs und Zeiger, sondern muss Objekte nehmen und hin und her reichen. Dieser Overhead frisst.

Hab jetzt mal die Geräte mit 10.000 Durchläufen getestet (zum Vergleich werf' ich die Werte aus dem Simulator/Emulator hinten ran)
HTC One V: 1.63s (6.93s)
Galaxy SII: 0.93s (6.89s)

iPhone 4S: 0.65s (0.83s)
iPod Touch 4G: 1.12s (0.84s)

Ich werde mich mal ob des NDK schlau machen, aber so schlecht ist das ja gar nicht.
Da hat mich wohl der Emulator ins Boxhorn gejagt.
Danke.

Kogoro-Christopher · 7. Februar 2013

Also wenn man sich bei Android auf eins verlassen kann, dann das der Emulator zu nichts taugt. Lädt ewig und hinterher hat man auf Devices dann Fehler, die auf dem Emulator nie aufgetreten sind. Am besten also immer auf einem oder mehreren Geräten testen

Marco Feltmann · 7. Februar 2013

Was war noch gleich so toll an Android? Und wo bekomme ich jetzt einen Schwung von zusätzlichen Testgeräten her?
Naja, zwei Geräte zum Testen sollten erst einmal reichen. (Leider bekomme ich meinen Freerunner nicht mit 2.3.3 zum Laufen und mit 2.2.1 generell nicht zum Entwickeln. Das wäre doch mal die Performance-Negativ-Referenz.)

Wie dem auch sei, das NDK scheint mir sehr zu gefallen.
Mal schauen, ob ich das sauber eingebunden bekomme.
Ich berichte.

C in Android nutzen: Geht's primitiver als Java?

Jetzt mitmachen!

Teilen