1. Nimm jetzt an unserem Uhans - 3. ADVENT - Gewinnspiel teil - Alle Informationen findest Du hier!

SQLite-Performance

Dieses Thema im Forum "Android App Entwicklung" wurde erstellt von Tom299, 20.04.2012.

  1. Tom299, 20.04.2012 #1
    Tom299

    Tom299 Threadstarter Android-Experte

    Beiträge:
    602
    Erhaltene Danke:
    120
    Registriert seit:
    31.08.2011
    Hi,

    ich hab gerade ein großes Performance-Problem in meiner App festgestellt: Die ganze Zeit habe ich mit "normalen" Daten getestet, die Anwendung lief einwandfrei ohne spürbare Verzögerungen beim Anzeigen von Daten in Listen.
    Das waren Daten im Bereich von 100 - 300 Datensätzen.

    Jetzt haben wir einen Stresstest initiiert und 5000 Datensätze eingespielt. Meine Anwendung bleibt jetzt erst mal "hängen" (Daten werde nicht im Thread gelesen, war bis jetzt nicht notwendig) und nach mehreren Sekunden bzw. manchmal nach bestätigen von "Warten" anstatt "Anwendung beenden" kommen dann irgendwann die Daten bzw. ein leeres Grid, wenn keine Datensätze gefunden wurden.

    Ich hab das jetzt mal lokal auf dem PC mit SQLite Expert Prof. getestet, da geht das Abfragen wie gewohnt sehr zügig.

    Kann das am RAM des Handys liegen oder kann man irgendwelche Einstellungen zur DB machen, damit die Performance gesteigert wird?

    Ich bin ehrlich gesagt etwas schockiert, daß die DB scheinbar nicht mit 5.000 Datensätzen klar kommt, wobei 5.000 jetzt ja keine allzu große Anzahl an Daten ist ...

    Jemand nen Tip für mich?


    Gruß,
    Tom
     
  2. swordi, 20.04.2012 #2
    swordi

    swordi Gewerbliches Mitglied

    Beiträge:
    3,389
    Erhaltene Danke:
    441
    Registriert seit:
    09.05.2009
    naja erstmals Threads verwenden.

    alles was länger dauern könnte, muss in threads. auch wenn es mit 100 datensätzen schnell geht. es wird noch immer eine datei gelesen und das kann aus irgendwelchen gründen auch mal länger dauern. wenn du viele user hast, tritt das dauernd irgendwo auf und die user werden damit keinen spaß haben.

    zweitens:
    nutzt du transaktionen? das beschleunigt abfragen ungemein. versuchs mal
     
  3. Tom299, 20.04.2012 #3
    Tom299

    Tom299 Threadstarter Android-Experte

    Beiträge:
    602
    Erhaltene Danke:
    120
    Registriert seit:
    31.08.2011
    Transaktionen hatten wir anfangs mal versucht, da kam aber immer ne komische Fehlermeldung daß er was nicht sql-mäßig kompilieren kann oder so. weiß nicht mehr genau, zu lange her ...

    Aber nur zum LESEN braucht man doch keine Transaktionen, oder seh ich das grad falsch?

    Das Auslagern in Threads läßt meine anwendung dann zwar nicht "hängen", aber die Liste bleibt ja erst mal leer und der Nutzer denkt er hat keine Daten und drückt gleich wieder den Back-Button ... es sei denn ich zeig ihm nen Progress-Dialog an, das wär ne Möglichkeit ... aber gefällt mir nicht so richtig.

    Gibts sonst kein Tuning für die DB? Wir benutzen extra schon Views in der DB, damit es schneller und komfortabler geht oder gehen sollte ;-)
     
  4. swordi, 20.04.2012 #4
    swordi

    swordi Gewerbliches Mitglied

    Beiträge:
    3,389
    Erhaltene Danke:
    441
    Registriert seit:
    09.05.2009
    naja dann zeig mal her was du genau machst. wir können es hier nicht erraten :)

    du sagst "nur zum lesen braucht man keine transaktionen"

    das ist korrekt. aber ein SELECT statement braucht auch nicht so lange wie du es beschreibst. da muss mehr laufen, von dem wir nichts wissen.
     
  5. Fonsi, 20.04.2012 #5
    Fonsi

    Fonsi Erfahrener Benutzer

    Beiträge:
    178
    Erhaltene Danke:
    15
    Registriert seit:
    08.07.2011
    Hier kannst du näheres über den Fehler erfahren ;-).
     
  6. Thyrion, 20.04.2012 #6
    Thyrion

    Thyrion Ehrenmitglied

    Beiträge:
    11,846
    Erhaltene Danke:
    2,451
    Registriert seit:
    21.07.2009
    Phone:
    Nexus 5X
    Das dürfte vom Statement und den Datenstrukturen abhängen. Aber ohne Datenbankmodell / Tabellendefinitionen und eben das SELECT-Statement wird es schwer, hier eine Aussage zu treffen.
     
  7. Tom299, 20.04.2012 #7
    Tom299

    Tom299 Threadstarter Android-Experte

    Beiträge:
    602
    Erhaltene Danke:
    120
    Registriert seit:
    31.08.2011
  8. Thyrion, 20.04.2012 #8
    Thyrion

    Thyrion Ehrenmitglied

    Beiträge:
    11,846
    Erhaltene Danke:
    2,451
    Registriert seit:
    21.07.2009
    Phone:
    Nexus 5X
    Was mir so beim groben Überfliegen auffällt:

    - Lass die Sortierung im View weg (und mach das bei der eigentlichen Abfrage, im Moment sortierst du nämlich doppelt)
    - Versuche SubSelects bei der Spaltenrückgabe zu vermeiden und binde diese, wenn möglich über JOINS mit ein (das sollte zumindest bei der Tabelle Termin und den MAX-Abfragen möglich sein).

    - Und in Java: Vermeide String-Verkettungen und nutze StringBuffer oder StringBuilder.
     
    Tom299 bedankt sich.
  9. swordi, 20.04.2012 #9
    swordi

    swordi Gewerbliches Mitglied

    Beiträge:
    3,389
    Erhaltene Danke:
    441
    Registriert seit:
    09.05.2009

    ja klar, aber es kann nie so lange dauern, dass das beschriebene verhalten auftritt.
     
  10. swordi, 20.04.2012 #10
    swordi

    swordi Gewerbliches Mitglied

    Beiträge:
    3,389
    Erhaltene Danke:
    441
    Registriert seit:
    09.05.2009
    dann ist der threadtitel wohl falsch. sqlite ist schnell - java ist langsam :D

    ich habe bemerkt, dass wenn man viele objekte erzeugt, dass sehr an die performance geht. eventuell hast da auch noch optimierungspotenzial
     
  11. Tom299, 20.04.2012 #11
    Tom299

    Tom299 Threadstarter Android-Experte

    Beiträge:
    602
    Erhaltene Danke:
    120
    Registriert seit:
    31.08.2011
    Erst mal Danke für Eure Bemühungen :)

    Also das mit dem doppelten Sortieren war mir gar nicht aufgefallen ... hab die Sortierung aus der View entfernt und siehe da, nur noch 4s anstatt 44s!!!

    Das mit den Sub-Selects muß ich mal genauer untersuchen, ob das mit einfachen Joins geht.

    String-Buffer benutz ich eher selten, ich denke beim Aufbauen des SQL-Strings braucht man das nicht wirklich, oder? ;-)

    @Swordi: Dass Java-Objekte Performance kosten können, hab ich schon zu Java-Zeiten erlebt. Hatte hier im Code mal die Objekt-Erzeugung auskommentiert, aber die Performance war unverändert bei 44s, was mich etwas verwundet, aber ok ...
     
  12. swordi, 20.04.2012 #12
    swordi

    swordi Gewerbliches Mitglied

    Beiträge:
    3,389
    Erhaltene Danke:
    441
    Registriert seit:
    09.05.2009
    na dann hast schonmal die zeit auf zehntel gedrückt. damit kann man bei mehreren tausend datensätzen schon eher leben.

    ein bisschen was wirst sicher noch drücken können.

    einen schönen lade indicator und der user ist glücklich :D
     
  13. Thyrion, 20.04.2012 #13
    Thyrion

    Thyrion Ehrenmitglied

    Beiträge:
    11,846
    Erhaltene Danke:
    2,451
    Registriert seit:
    21.07.2009
    Phone:
    Nexus 5X
    Das mit dem StringBuffer war auch eher allgemein gesprochen - aber gerade bei Systemen mit stark limitierten Resourcen (und dazu zähle ich Smartphones nachwievor), sollte man eben schonend damit umgehen. Und String-Verkettung ist nunmal sehr "teuer" (im Sinne von Speicher und CPU-Last).
     
  14. Tom299, 20.04.2012 #14
    Tom299

    Tom299 Threadstarter Android-Experte

    Beiträge:
    602
    Erhaltene Danke:
    120
    Registriert seit:
    31.08.2011
    Was mich jetzt noch verwundert: in dem Falle, daß ich KEINE Daten bekomme, brauch der Befehl if (c.moveToFirst()) { ... } stramme 4 Sekunden. Das kann doch nicht sein, oder?
     
  15. swordi, 20.04.2012 #15
    swordi

    swordi Gewerbliches Mitglied

    Beiträge:
    3,389
    Erhaltene Danke:
    441
    Registriert seit:
    09.05.2009
    wäre irgendwie komisch

    aber frag halt vorher ab ob daten vorhanden sind. ...getCount()
     
  16. TheEvilOne, 20.04.2012 #16
    TheEvilOne

    TheEvilOne App-Anbieter (In-App)

    Beiträge:
    452
    Erhaltene Danke:
    50
    Registriert seit:
    19.05.2010
    Lädst Du eigentlich ganze Table-Objects in Deine Liste, oder füllst Du sie mit abgespeckten Objekten bestehend aus Id und Anzeigestring?

    Das ist vielleicht auch noch ein Ansatzpunkt.
     
  17. Tom299, 23.04.2012 #17
    Tom299

    Tom299 Threadstarter Android-Experte

    Beiträge:
    602
    Erhaltene Danke:
    120
    Registriert seit:
    31.08.2011
    Nachdem ich gesehen hatte, daß in der DB noch ein paar Indexe auf Suchfeldern gefehlt haben, hat sich die Abfrage incl. Anzeige der Daten auf 3s-5s eingependelt, wenn man in der "Hauptansicht" ist.
    Ich denke, das ist zusammen mit einem Progress-Dialog dann schon akzeptabel für den Stresstest, wobei ca. 17.000 Datensätze in der DB vorhanden sind.
    Normalerweise befinden sich aber weniger Datensätze auf dem Handy, d.h. die Anwendung ist im Normalfall schneller.

    Danke nochmal an alle für die Tips :thumbsup:
     
  18. swordi, 23.04.2012 #18
    swordi

    swordi Gewerbliches Mitglied

    Beiträge:
    3,389
    Erhaltene Danke:
    441
    Registriert seit:
    09.05.2009
    dafür gibts den danke button :D

    gut 3-5 sek für 17000 datensätze ist ganz ok, denk ich
     
    Tom299 bedankt sich.
  19. Tom299, 23.04.2012 #19
    Tom299

    Tom299 Threadstarter Android-Experte

    Beiträge:
    602
    Erhaltene Danke:
    120
    Registriert seit:
    31.08.2011
    ja, im Normalfall sind es wohl eher 1500-2500 Datensätze als Spitzenwerte, im Schnitt weniger als 1000. Das sollte so passen :)
     

Diese Seite empfehlen