On Fri, 08 Aug 2003 14:17:36 -0400, Douglas Handy <[EMAIL PROTECTED]> wrote:
>Other programs and records has nothing to do with it. That affects the storage >heap size, not the dynamic memory size. Every Palm OS has the total memory >allocated by the manufacturer with a fixed allotment between storage vs dynamic, >and never the twain shall meet. Well, in the larger sense, you are totally correct. I realized that almost immediately after posting. Addition of applications etc, do (did) affect available heap but not directly or in a large way. It is mostly hacks as you say. >And 7500 bytes from the dynamic heap is NOT just 0.3% of the dynamic memory Again, you are absolutely right. But I want to know, why is it that writing large(ish) programs for four years, using dynamic memory freely for dynamic lists, why haven't I ever run out of heap? *Ever*? One reason, I'm sure, is that I don't consider large lists very practical ergonomic ally. As a matter of coincidence (I'm sure) I hardly ever write an application that uses static lists other than category names... And, BTW, a PIII is my LCD and sits in my cradle as I type. >If your list width becomes 30 bytes instead of 10, that same list now consumes >about 1/4 of potential memory, not .9% (ie three times your quoted .3% for a >width of 10). What if you have several popups on your form? ...and once again, why not use *all* the heap? Have you ever run out? > >In your sample buildList() function, you included the line: > > char *src=GetAListItem(i); //this is simplified for brevity > >If the text is really obtained by an encapsulated call like that, it is trivial Did you notice the comment on the line? The point was that it is not complicated to create a list...whatever GetAlistItem represents, it is required in either implementation, isn't it? It may well require fetching one or more DB records and converting non-readable fields to a human representation and concatenating them. Work once done that is preserved by LstSetListChoices for future reference by LstGetSelectionText() (the cause of this thread) or for incremental search. >to use a drawlist function. Until you want to retrieve the text by index, or you want to enable speed search. >The callback just invokes GetAListItem() then draws >it at the coordinates passed to the callback. Well, thanks. The point is that whatever *it* is, it is a necessary complexity for either method. Somebody here was talking about how hugely complicated it is and how awful the memory management is and so on...it's not. >Look ma, no dynamic memory consumed. And you get a prize? How many times have you run out? Why don't you want to use the Dynamic memory? > >>When a Custom DrawList is called for (with it's attendant execution >>for *each* item in the list), > >Wrong. It only gets called for each *visible* item. That's what I meant, of course. "the list" was meant to imply the "visible list" as that is the only part that a custom drawlist callback addresses...one item at a time. >>how much easier/faster is it to simply >>fetch the text from your own store which is already built? > >That depends. It can be extremely simple to fetch the text from the same place >that GetAListItem() gets it. GetAListItem is usually far more complicated. It is often generated (at least in my programs) from non-string fields in (possibly non-sequential) DB records. >>>Hence, the system >>>/ought/ to be able to accept a callback so that it can retrieve the text to a >>>list item whenever it needs to. >> >>That's a thought, but is it realistic? > >Sure it is. By definition incremental search only works with a sorted list, >which is precisely where a binary search is very effective. (Consider how >DmFindSortPosition works.) > >>Each character addition would force >>a fetch of all text through the callback... > >Do you have any idea how binary searches work? Yes I do, but you missed the point. What makes you think an *incremental* (aka speed) search is binary? >You absolutely would not need a >fetch of all text, nor would you get inconsistent results. No, you would need a fetch of all elements, starting with first, until the first character is satisfied with a match. Type a second character, and the second character of the current item is tested and if not satisfied, then the next item is fetched. Setting up binary search for this sort of thing does not have any payback when you have the list in an array... On the second character you would have to reset the bounds of the search and repeatedly bisect, only to find that there are no more items starting with the (already matched) first character. It's senseless. I have it enabled and sitting in front of me. It is not just the visible parts of the list...It doesn't require a sorted list for the algorithm. The speed search is as useless or worthwhile as you expect when the data is not in order. It will work until it doesn't, if you take my meaning. Also, it honors backspace in-place, repositioning the list to the prior top-hit. >Whether a binary search or sequential search would be preferable will depend on >the number of items in the list, but the OS knows that too. >Either way, it never has to fetch all the text. aaaa aaaab aaaac aaaad ... aaaaz Yes, it does. >>The code is already there. The API already does what you want. >>Applications that use LstSeListChoices() use it freely, because it costs nothing. > >It costs dynamic memory, which can be a real issue in 2MB devices (or earlier, >but I don't worry about them...). Like I said, though my code is full of tests for heap failure, I have yet to see one. >It also costs time when the form is opened, 1) irrelevant IMO, nobody cares if a program takes a few Ms to load. They care how it works, and if it has the features they expect. 2) "Lazy evaluation", I never build the lists until the form they are on is opened and occasionally, not until they are popped. I haven't seen any perceptible delays in program loading, form switching or list appearance. But then again, I don't make huge lists...anything large generally winds up in a scrolling table, or has some method to 'drill' the presentation set to something manageable. The materials that I work on demand more context than a single word. >>I've been writing for the palm for several years. > >Then how could you not understand the difference between storage heap and >dynamic heap on a Palm OS device? That's a mistake born of not having been interested in those aspects for several years. I work on a half dozen platforms, and though I knew my mistake almost as soon as I posted, it has no effect on the position...In fact, the mistake was made in an attempt to concede a weakness - i.e. that available heap may shrink over time. You have quite rightly eliminated that weakness. > >>I remain steadfast in my conviction that LstSetListChoices should be used >>in all but the most trivial cases. > >Aside from design-time static lists (the most trivial cases...), I remain >steadfast in my conviction that drawList is the preferred method. >Of course, this also means I am not using incremental search. >>and the best way to get there, with the smallest >>amount of code is to use the API the way it's designers intended. > >And the least amount of code to get there is to use your GetAListItem() inside a >callback, and just draw the string at the coordinates given. All the rest of >your code is completely unnecessary, consumes dynamic memory, and forces the >form open routine to fetch all the rows for every list and popup. ...Yeah but I'm not the one telling the Palm guys that they need to change the API to suit my implementation (c; My listBuilder is proprietary, I won't show it you, or even the method signature, but there is only one copy of that code in any program and except for one case, it (alone)supports all the dynamic lists in all the forms. I'm pretty sure that is 'less code' than a custom listDraw call back for each list. I already showed the basic structure that permits lazy evaluation, single pointer allocation and deallocation...the hub-bub about memory management complexity and leaks is way over done. It's just not that hard. >I maintain it is *faster* to only fetch rows as they are needed (or *if* >needed!), it conserves memory, avoids the need to free memory or have a memory >leak, and takes *less* code to implement besides! I don't think the 'Less code' is true. I don't think the faster part is true. In list scrolling, it certainly is not. I don't see the value in not using an available resource, but you're right, it "consumes" memory. Memory which (as I understand it) was put there to be used. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
