On Feb 2, 2:00 pm, "Mark Murphy" <[email protected]> wrote: ... > A Cursor represents the entire result set. If you run a query for 20K rows > and 5 columns, you will instantiate 100K objects at the time the query is > actually run. ...
Actually, that shouldn't be quite right. (I know you know this, but were focused on making your main point. I just want to clear up any confusion). A Cursor should represent a result set + a movable index in that result set. The major reason for using a cursor, is precisely to AVOID simultaneously allocating space for all 20K or 20M or 20B rows. Now, a naive implementation is, certainly, to load in all the results from a query. But a PROPER implementation will: 1) analyze the query 2) form a query plan -- sort of a mini program for generating the query result. 3) on request for the first row, begin executing the plan, one or a few rows at a time. The portion of the query results that have been read are "the window". 4) Once you've read the data from one row, and move to the next, the storage can be freed. (Everything but the final reading should happen on the database side, to avoid doing unnecessary work on the query). Note that, at no time, have you allocated 20K rows worth of objects. Yet, by the time the task is done, IF you actually read ALL the objects, you you'll have allocated each of those 20K rows's objects. In fact, if you move back an forth, you may allocate a good deal MORE. But the garbage collector will save you, and your peak usage will only be a few rows worth. It's important to note that a cursor can't completely save you from an expensive query! Behind the scenes, the database may have to do some very storage-expensive work -- like sort the results of a complex query. To do this, it may need to first collect ALL the rows, and then sort. Indexes may help in some cases. This is the sort of thing that makes database programming an interesting challenge sometimes... But even in this case, there's a benefit to getting your results via a cursor. You may need to have a complete list of rows - but you won't need to turn those rows into Java objects until you need them. So you won't need as much storage all at once. This all works very synergistally with your CursorAdaptors! Just stuffing all 20K rows into a ListView isn't going to save you anything. But if 10 items fit on your screen, only asking for about 10 items is going to save you a factor of 2K in peak storage. And if you only look at one or two screens, the performance difference will be huge! Anyway, you've just convinced me to go get your book. It's got to be worth it, just for a pre-written EndlessAdaptor implementation! (Yes, I can download it, but..) -- 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
