Ben - that makes sense. And I read your blog entry on the subject (Google first link for "nand flash"). But wow does it suck in this case. Good for NVRAM and whatever, but this is going to be like PPC on the XScale, where the new device runs noticeably slower than the old one, at least in some important ways. Stock Answer: "Oh, you have to optimize your apps (or the OS) for it."
Anyway, this produces a statement and a question: 1. I've talked with the other people on my team, who have a lot more knowledge of how our database works exactly, and there are more reasons than I'd remembered for why we really want individual records for each of these items (we're using some of the padding bits for relationships to indices, for example). It may not work to change that architecture. That said, one of the primary reasons for the architecture is performance on slow devices, and if there's a bit of a speed hit on the T5 and anything else with the same memory architecture, it's relatively small and we can probably deal with it. App performance is reasonable, startup and shutdown suck because of loading to cache when opening DBs, c'est la vie. 2. The size thing, on the other hand, is just not good. There's no way we can eat 20 meg of storage with 2-3 meg of real data. I can't find anything on the PalmOne site that might help us understand how the padding and caching and whatever work, and if there are any tricks to help us circumvent it. And is the only reason it wants record size relatively large that it can immediately do a commit to flash without waiting for other data in its sector to change? That part does confuse me a little bit. Does anyone have any good technical documentation they'd be willing to share? I am reading up about NAND and NOR flash in general as we speak, but I don't think any of it is going to speak directly to this issue. Thanks for everybody's help... -d ---------- >So, back to the root question: I don't love that PalmOne seems to have >changed the rules on this non-minor issue. It really cramps our style. >If it's a hardware issue, I guess we're stuck changing the DB and >rewriting our code, but that really isn't going to happen by the end of >this month. Boo on PalmOne if that's the case. It's a speed thing -- they've got a serious speed issue involved in writing data to NAND flash, since you can only read or write to that in whole-sector amounts. Since they are doing record-level caching, they may have a lot of random records in the DB that have been modified when it comes time to flush it back to NAND. The padding means they are much more likely to be able to modify the record in-place, making that operation a lot quicker; if they weren't padded, then they may have to read in the whole DB and write it back out, just to flush a change to one record. Now, I think this could be improved, but it's hard to give NVFS enough information about your DB's use semantics to let it optimize things; it would be nice to be able to give it a "this DB is never or rarely modified" flag which would let it pack it more, but I don't think anything like that exists. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
