I am writing an iPhone app that uses SQLite. I am use to opening and closing my connections every time I use a database. However, I do not know if that is a good practice in the iPhone/SQLite environment. I want to know if I should open the database 1 time or if it is OK to open and close the database each time I use it. Please let me know.
I believe you should keep it open as long as you can, so data is cached in DRAM. Of course, you should also organize your transactions so you commit at logical points in time and maintain transactional integrity.
I would do as Matthew suggested: keep one connection opened for as long as your program is running.
Both answers seem right, but actually it depends from how often you're using it and how large is it. In case DB is large you should set larger page cache, but that leads to larger memory consumption and if access is rare - no reason for holding it up all the time (but if usage also small - large page cache won't help you also).
In case it's small - there is no reason to open/close it each time even with infrequent usage. But in average your resource consumption is higher with regular open/close. So all in all - don't reopen db each time you're using it.
Related
I created a web-app that utilizes db.collection.watch() to observe database changes.
However, after a few weeks, the app becomes sluggish and I have to fix it by restarting the backend - which hints at some memory leaks.
My fear is that my db.collection.watch() calls are not being properly closed, so it would be helpfull if I could see how many are actually open at any given time.
Is there a mongo command that can provide this information?
Hello I'm new to this forum (signed up today... have always used it for reference in the past though) and new to iOS development (6 months), but not a new programmer. I'm creating an app in iOS 5 for iPad that will require the user to rapidly input and update data (mainly adding, subtracting , changing BOOL states, etc... with time between events less than 2 seconds at times) for numerous objects. It is currently designed to use a SQL database, but worry that with rapid entries and updating that the database will get corrupt if it is not opened and closed rapidly enough. Any suggestions or lessons learned from iOS/iPad/iPhone experience? Is SQLite a preferred method for rapid input or should I switch to something else? Thanks and taker easy!
Core data handles all of the database connections for you. Changing properties on your managed objects doesn't involve a connection to the database every time, it just updates the objects in memory. The database is updated when you save the context and probably periodically in the background - the point is, you don't have to worry about it.
Don't code around a problem that doesn't exist - write your app using core data, and if you get database corruption problems, investigate then. But I doubt you will have anything to worry about on that score.
Can you please give some suggestions on sqlite using on the iPhone?
Within my application, I use a sqlite DB to store all local data. Two methods can be used to retrieve those data during running time.
1, Load all the data into memory at initialization stage. (More memory used, less DB open/close operation needed)
2, Read corresponding records when necessary, free the occupied memory after using. (Good habit for memory using, but much DB open/close operations needs).
I prefer to use method 2, but not sure whether too many DB opening/closing operations could affect app's efficiency. Or do you think I can 'upgrade' method 2 by opening DB when app launches and closing DB when app quits?
Thanks for your suggestions very much!
First of all: use FMDB to access SQLite!
Then, create your own singleton "MyDB" class.
Every time you need the database, you do [MyDB instance] to get your FMDB instance.
That way you only have one DB open (in didFinishLaunching) an you close it when your app exits.
That's far and away the best way to use SQLite on the iPhone.
The other option is to use CoreData, something I find great for when you start with an empty database, but FMDB/SQLite works best for me if I have a set of data that's read-only.
Apple seems to suggest that you avoid preloading all the data during the startup in order to ensure faster and smoother startup. Supposedly you should only load data when/if the user needs it.
We often cache image and data to improve our iPhone app's performance. But what strategy do you use to manage the cache data, such as delete or update it?
I saved the images to TMP folder, but don't know when should I trigger to "checking out of date cache data and delete it": when the iPhone apps starts, or quits, or in idle time?
You should delete the cache when the iPhone invokes your "didReceiveMemoryWarning" function.
When the application launches or quits, the user is usually expecting responsiveness. Choose a minimum amount of real time, like 24 hours, and a minimum amount of idle time, like a minute. If the user has been idle for a minute and it is more than 24 hours from the last cache purge, then clean the cache. If you are keeping track of how much data is cached, then you could factor that in as well. If it has been more than 24 hours and/or there is more than a megabyte in the cache.
If you are sure the application is being quit normally, as opposed to being quit to answer a call or launch another application, then that might also be a good time.
If your application does something that the user has to wait for anyway, but that would not be affected by purging the cache, then that might also be a good time. For example, fetching some data from a server.
Appreciate for your responses.
I agree that checking for delete the cache at the start or quit time will reduce the program's performance. Moreover, quit time is also used for saving the program's state.
The idea to check for idle time in 1 min is quite ok, but I have to build mechanism to check idle for every 15 s during the application time. I don't think it's easy and good for performance.
At last, I decide to perform "check and delete cache" after I retrieve new Items (data + image). I will check for items (data +image) that doesn't need to be displayed anymore and delete it. I think it makes sense that the feature who saves the cache, will deletes the cache also.
Certainly, I will do this in another thread to avoid frozen the interface.
Is this good? Pls give me your opinions.
I personally dosn't like if cache is cleaned when i open a application or idle longer then about 1 minute. The idea cleaning if age of the cache is about 24hours is good.
My personal recommandation is to build stack of cache files. And then checking for the cache file creation/modification time or last cache file access. So clean in background (don't let become your app feel slow cause you're doing such tasks when starting or stopping an app) maybe in a thread (does iphone sdk support that? dont know :)) and check for "is cache file older then 24hrs? if yes > recache or delete file
To be clear, this is for a normal iPhone application, and not a game.
I've read around the web a few times some developers mentioning that they were working hard to improve/reduce the startup time of their applications, but never with any good background information on how to do so.
So the question is simple: how can you reduce the startup of iPhone applications?
Same as any other performance issue: Use Shark and/or Instruments to identify bottlenecks in your code, and then focus on how you can speed things up there. Each tool will give you a picture of how much time was spent in what parts of your code, so the general scheme would be to run the tool while you start the app and then pore over the data to see where the performance hits occur.
At app startup time, the most likely candidates for improvement will be deferring data loading until later on when it's actually needed, variously described as "on demand" or "lazy" loading. Essentially, don't load any data at app startup unless it's actually needed right away when the app loads. In practice, lots of stuff that may be needed at some point doesn't have to be immediately available when the app starts. For example, if you have a database of N records but only one is visible at a time, don't load all N into memory at app startup time. Load whatever the current record is and then load the others when you actually need them.
James Thomson did a nice blog post documenting his efforts to make PCalc launch faster.
Of particular interest is his use of image with screenshot from last app run, to pull the same trick Default.png does, while loading rest of the app.