Regarding the I/O - Until you verify it, it's all conjuncture :) Regarding caching the DB - A lot of system do cache portions of the DB, some DB systems are actually memory based.... so nothing special there, it all depands on the purpose of the database.. not all of them are for storage purposes.. i just never checked if SQLite on android attempts to cache anything... though considering how slow it is from my experiance, i guess it only caches queries, not data.
On Thursday, May 16, 2013 11:58:13 PM UTC+3, Nathan wrote: > > [image: Attach a file] Attach a file > Edit subject Quote original Add Cc > > > > > On Wednesday, May 15, 2013 3:18:12 PM UTC-7, Piren wrote: >> >> How much is too much? >> >> >> Obviously i don't have an answer for that... but if the device freezes >> and you could pinpoint the issue to these requests, it's safe to say that >> you've gone over the limit for that device :) >> > > I agree with that - if I can succeed on the first two. I still don't have > the device. Anyone close to Portland OR with Droid Razr Maxx HD? > > I wonder how much is too much because Movies, for example, can stream an > entire movie to storage and retrieve it and display it in realtime. I think > that is much greater load than I am putting on it. > > >> What drive isn't flash? I'm assuming that app internal storage (I don't >>> use), external storage, and removable external storage are all flash. >> >> Meant the internal drive of course. Unless you pushed the DB to the >> SDCard, it uses the internal storage btw, any either way DB access is I/O. >> > > I don't push the DB to SDCard, I create it there in the first place. > Extremely advanced users can actually choose an external SD Card. > There is a mode that uses a lot of little files, and another one that uses > one big DB with lots of binary blocks. > > >> By System blocking i meant that all drive access eventually is on a queue >> ... (not that it blocks the entire system thread wise). >> > > That is something I would expect, and therefore multiple threads could be > blocked waiting for that. > > >> So hammering the DB with requests is a nice way to make the entire device >> unresponsive. >> > > >> I've never actually checked if keeping the DB open will load it to >> memory, >> > The whole thing? It better not. That's not my understanding of how > databases should work. > I'm not sure what size of DB you are used to working with. > > >> but if you know you have lots of DB access, it's a good idea to cache it >> in memory anyway. >> > I believe as much caching as should be done is already done. I wouldn't > use a database or the file system at all if the whole thing could fit in > memory. > > Nathan > > > -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
