Excellent reply and very informative! > So, just because of trap overhead, I wouldn't put it > in a tight loop.
Yeah that was my intuition too. For that reason I'd also considered... > (use a hash and make it 2- or 4-way associative), it Sheesh I shoulda' known if I didn't mention this... :) Yeah I considered various lookup and "in use" mechanisms but it's apparently not as many strings as apps are accustomed to using! > I do actually have one app where I have literally hundreds of thousands of strings (...) Wow! No I don't have thousands but it's good to know it can be done. Few dozen is all. Thanks, I think I will go with the keeping them locked throughout, I was leaning that way anyways. Thanks for your very helpful response! Gary Douglas [EMAIL PROTECTED] --- Logan Shaw <[EMAIL PROTECTED]> wrote: > Gary wrote: > > > Or rather how slow is it? > > I'm not exactly sure about that. I do know it will > have to have > a trap, or at least two traps (one to lock and to > unlock) since > that is how system calls are implemented, but beyond > that I'm > not sure. So, just because of trap overhead, I > wouldn't put it > in a tight loop. Best bet is a benchmark, though. > > > I ask because I have a buncha strings that might > get > > opened/closed alot, so I must either: > > > > a. lock/read/unlock each time data needed > > or > > b. lock all potential strings at startup, unlock > them > > all at cleanup > > Well, strictly speaking those aren't the only > options. You could > manually go over the code and determine which ones > will be accessed > most frequently, then keep those around. Or, you > could even keep a > cache of frequently-used handles. If you make the > cache simple > (use a hash and make it 2- or 4-way associative), it > could be quite > fast. Although, hopefully it's not necessary to go > that far. > > > I guess I'm also presuming there's some > disadvantage > > to having them all locked (memory? handles?) and > it > > just seems untidy to boot. > > As far as I understand it, the advantage of handles > is that it > allows you to defragment the heap (either the > dynamic heap or > the storage heap, depending on where the handle > lives) without > the need of hardware assistance. When an allocation > fails (or, > whenever you feel like it), you simply go through > all unlocked > handles and rearrange that memory to minimize > fragmentation. > > The corollary to this is that if all the handles are > in the > dynamic heap and you are nowhere near running out of > dynamic > heap (perhaps in your case, the strings are the only > thing > stored there or something), then there is no > disadvantage > to keeping the handles locked. Plus, if the handles > are to > the storage heap and you never use the storage heap > while your > program is running (you don't save to the > preferences database > or any other database), then it probably doesn't > matter much > either. > > > Should I be concerned with the overhead of > > locking/unlocking? Are you? > > I'm not concerned, but then I don't have thousands > and thousands > of strings each in their own MemHandle. (I do > actually have one > app where I have literally hundreds of thousands of > strings, but > they are in a special read-only data structure...) > > - Logan > > -- > For information on using the Palm Developer Forums, > or to unsubscribe, please see > http://www.palmos.com/dev/support/forums/ > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
