I'm developing an application for Android, and have tried to use ORMLite, but the performance seems to be really poor. Has anyone else experienced this?
Or am I doing something wrong?
EDIT
No I'm not doing any joins, and all queries are made with indexed keys as parameters. But the data set is resonably big, and there is quite many comparisions.
Haven't tried to do with pure SQLite...
I guess the best answer is that the performance of ORMLite is highly dependent on how you use it. If you could post some of the code samples as well as some of the performance numbers, we may be able to help more specifically.
If you are making a number of database operations at one time, you should consider using the Dao.callBatchTasks() method. Under Android, it starts a database transaction, calls the passed in Callable and after it returns, it commits the transaction. This is significantly faster if you are, for example, inserting a number of rows into the table.
See also: Why is the DAO method so slow in ORMLite?
EDIT
If your queries are taking a while then most likely the time is being spent in SQLite. You could try reducing some of the dataset or tuning the number of comparisons to see if things run faster so you can definitively determine that SQLite (and more likely just IO) is the culprit.
Related
This is a general sqlite question and specifically as implemented on Android.
Which offers the best peformance if a deletion on one table would require deletions on another? This can be accomplished three ways that I see:
To use a trigger
DELETE statements
A Transaction wrapping the DELETEs
Hope I've phrased it correctly, I can muck around in sql but I might not express myself properly.
The only real way to answer a question like this is to build a test case, and try it.
There are many things that can affect the execution time of a statement, and when you start adding things like triggers and transactions, the number of variables grows even more.
Write a simple test case, specifically for your application, and see which works faster for you.
Also, be wary of premature optimization.
is it true that a DBMS can optimize the access to a View by performing the query that defines the View only when the data that is backing the View is modified and not everytime I query the View itself?
EDIT
What about SQLite for Android?
Delamere,
The answer to your question depends largely on your implementation of the Views, the Database queries, and the underlying structure. In essence, the core issue is the nature of the data and how often it needs to be requeried.
In some of my published apps, I have data that only needs to be queried whenever the Window receives focus. In these cases, a simple manual refresh is called. These are often atomic queries meaning they are miniscule amounts of data. Using this method, I've bridged many apps and their data together into a cohesive almost instantaneous query.
In other cases, the data changes quite often but predictably. In these cases, it is counter-productive to reduce the number of queries, but it is also ineffectual to bind an observer.
Finally, there are several cases where the data will change irregularly and the amount of change is unpredictable. In these cases, the optimal solution is to utilize an Observer. This will make sure that only the queries that need to run are run. And the views will be updated as soon as the adapter is updated.
In reference to your question, the final scenario (I think) conveys what you are asking. In short, the answer is yes.... *but... * refer to the first two scenarios. To decide on the optimal solution for yourself, you need to have the answers to the following:
How much data are you querying at any given time?
How often will that data change?
Could it change while your app is running?
Once you have the answers to those questions, you may align your solution accordingly. Without more information, this is the extent of the guidance you will probably receive. I would also strongly advise that if you aren't familiar with basic database engineering concepts, that you familiarize yourself with the concepts of normalization, relational models, and indexing. A strong understanding of these can greatly improve the performance of your database, your app and the appropriate Views.
Hope this helps,
FuzzicalLogic
It took me about 4 hours to follow an example in a book about android, where they showed the code for just a table. I had 6 tables, so I extended the class for every table I had. Dirty but effective. The problem appeared when I was deciding how to access to related objects. For instance, I have a Piece object, which has a list of pieces (using a table which connects a piece to another piece). Well, suppose each Piece can have up to 15 (on average) of those pieces, and I need to access them as an object (not as an index).
This sort of connection was not commented in the book, and I came up with a good (yet really slow) way of getting these, by querying for the related pieces indexes, and then getting them just as a regular Piece (with a getPiece(long id) method). The big problem is that it takes about 5 seconds to load 10 Pieces with their related pieces.
I was wondering if there is an already defined Data Acces Layer styling for complex objects in Android. (I got used to the way Yii framework for PHP does)
Do you know any good implementation for getting related objects fairly fast? Thanks in advance
Well, it's been a long time, but I'll write what I'm using right now. It's ORMLite: It's not what I expected to be, relations are still a little pain, but hey, at least it encapsulates all the procedures.
I'm fairly new to android but I have some J2EE experience. I am working on an android application and my model makes use of the composite pattern, and in addition some of the objects will contain a list of other objects. I understand when dealing with mobile apps, I won't have as much memory available and when looking at my design, I will probably end up loading a lot of objects in memory with my current models when I'm querying the sqllite database. So my question is for people who have worked in both worlds, did you have to make changes in the way you deal with objects (how you populate them from the database etc...) to make the application run faster?
Thanks!
Not really. You can use SQLite or db4o if you prefer a non relational dbms.
Just read the best practices for performance and responsiveness and you'll be alright. Don't worry about performance issues until you find them in your app. You can always optimize later.
Executing multiple SQL statements without putting them into one transaction is a severe bottleneck (see e.g. http://www.sqlite.org/faq.html#q19). I haven't thoroughly checked how SQLite is configured on Android, but anecdotally I perceived dramatical performance increase within my on app when using transactions in more places.
Is it possible to detect instances where one forgets to use transactions using StrictMode? If not, could that be considered for a future release of StrictMode? It might be somewhat tricky to detect, but two different strategies could be, 1) non-select statements outside transaction, or 2) multiple non-select statements outside transaction executed within a short period of time.
Yeah, that sounds like a good thing to catch. I could imagine an API like:
StrictMode.catchWritesOutsideTransactionsOn(SQLiteDatabase db);
We've been considering other SQLite hooks into StrictMode (mostly around selects missing indexes and such), but this is a good idea too!