Here is the interesting issue observed on the Motorola V3M. Application (in fact it’s VM) startup time deteriorates.
When midlet owns multiple RecordStores it’s startup time is painfully slow, in fact you don’t even see any message from the system that it is doing something, as the phone simply freezes. So far I found out that V3M freezes for about 0.5s for every RecordStore, so if your midlet has about 100 record stores as mine has, it takes about 50 seconds to startup, OUCH!
So I’ve reimplemented the persistence layer instead of using single record store per cache entry, use single RecordStore for all the cache, and then store each cache entry into a Record.
Now here is another problem, when you delete record RecordStore.deleteRecord(recordId) the system does not reclaim that memory, it simply marks it deleted. Same happens if you do setRecord(new byte[0]{}, 0, 0), it still does not reclaim the memory. The only way to reclaim the memory is to copy only life data into the new record store and delete the old one, pretty much re compact it. Well it is a slow operation, and how often would you do it? AS for writing 400K it takes about 5-6 seconds on V3M, and it is such intensive operation, that even repaints don’t go though.
Well, i wouldn’t write this post just to rant on the device, as I’m so used to the limitations of the mobile devices. I do have mini solution, at least the one that works for me.
Thanks God, V3m has 6 megs of heap, so i keep my 400K of cache in memory, and on user inactivity( as well as pauseApp and destroyApp), i simply flush it to RMS into the single RecordStore and single Record inside of it. So it works pretty fast, as I don’t have to read it, and i do not delay UI by expensive recomapacting, my startup time is also blazing fast.
technorati tags: j2me motorola v3m razr rms