Thanks Dianne. That helps alot. The reason I asked is because my ContentProvider will allow other applications to insert into it, similar to a logging system. Since I can't guarantee an application won't try to abuse it, I was just trying to figure out what type of safeguards to put into it.
I'm very interested in exploring the responsiveness of the UI to large cursors. On May 12, 6:47 pm, Dianne Hackborn <hack...@android.com> wrote: > The storage is very compact, but you definitely want to limit the result set > as much as possible especially if there are a lot of results. Note that at > the end of the day, SQLite will generate a complete result set of the query, > so whether it is windowed or not doesn't really save the amount of peak > memory. If you are seriously contemplating having results of 100K items, > you absolutely need to do some up-front prototyping on real hardware to see > how it will be handled, not just for memory but also the time to do the > query. I also have to wonder how someone is actually going to be able to do > any kind of reasonable navigation of that many items in the UI (and relying > on filtering is kind-of questionable because I can't imagine the results > being returned quickly enough to make UI response from filtering all that > pleasant). > > But who knows, you'll just need to try it out. > > As far as memory accounting, this memory is shared between the processes, so > it should be accounted to both of them. > > On Tue, May 12, 2009 at 6:35 PM, Jonathan Herriott <herri...@gmail.com>wrote: > > > > > > > > > So, I'm guessing I need to limit the number of rows that can exist in > > a ContentProvider, so as to avoid memory issues if per some strange > > chance the provider has a ridiculous number of rows. I'm actually > > going to go and test to see if there is any significant change in the > > amount of application memory usage between a query of only a couple > > items, and a query of, say, 100K from the perspective of the client. > > I honestly don't know which user/application the shared memory is > > associated with, so who gets hit with having to store the result set > > in their heap? Maybe I'm over thinking this and I shouldn't worry? > > > On May 12, 1:43 pm, Dianne Hackborn <hack...@android.com> wrote: > > > Actually I am mistaken -- we haven't done windowing for a long time > > > apparently. :) So the result of the query is generated into a shared > > memory > > > in total that the client can read. > > > > On Tue, May 12, 2009 at 1:34 PM, Jonathan Herriott <herri...@gmail.com > > >wrote: > > > > > Hi Dianne, > > > > > That essentially answers my question. I was curious as to what > > > > happens when you query, say, a database that contains 100K rows, how > > > > it effects memory. From what you said, I'm assuming that it stores a > > > > subset in shared memory, and when the window moves, the subset > > > > changes, thereby eliminating any worry about running out of memory for > > > > large queries. > > > > > I guess my issue is that I'm having a difficult time tracking what > > > > objects are being supplied for interfaces (IContentProvider, etc.). > > > > Does there happen to be a resource file which shows which objects are > > > > being used, or do I just need to spend more time studying the code? > > > > > Thanks, > > > > Jonathan Herriott > > > > > On May 11, 5:50 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > Not sure what you mean. The content provider runs in its own > > process. > > > > When > > > > > you do a query, the results are windowed in shared memory for access > > by > > > > your > > > > > process. > > > > > > On Mon, May 11, 2009 at 3:39 PM, Jonathan Herriott < > > herri...@gmail.com > > > > >wrote: > > > > > > > I was diving through the Android code on how ContentProviders work, > > > > > > and to me, it looks like any ContentProvider I query actually gets > > > > > > placed entirely in the memory of the requesting application. Are > > they > > > > > > really stored in the querying application's memory? For some > > reason I > > > > > > thought the cursors were lazy. > > > > > > -- > > > > > Dianne Hackborn > > > > > Android framework engineer > > > > > hack...@android.com > > > > > > Note: please don't send private questions to me, as I don't have time > > to > > > > > provide private support, and so won't reply to such e-mails. All > > such > > > > > questions should be posted on public forums, where I and others can > > see > > > > and > > > > > answer them. > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > hack...@android.com > > > > Note: please don't send private questions to me, as I don't have time to > > > provide private support, and so won't reply to such e-mails. All such > > > questions should be posted on public forums, where I and others can see > > and > > > answer them. > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
