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 <[email protected]>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 <[email protected]> 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 <[email protected] > >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 <[email protected]> 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 < > [email protected] > > > >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 > > > > [email protected] > > > > > > 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 > > [email protected] > > > > 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 [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
