12-01-2009 05:11 PM
Compress the data before storing it and uncompress when retrieving it? Store temporary files (with FileConnection) for persistence instead of using NVRAM?
12-01-2009 05:41 PM
I would like it if you could format the internal memory so one partition is for data and the other partition is for apps, or to have the OS, Core Applications, System Software, and persistent store had there own memory.
This way the 128mb of app memory was actually 128mb of app memory instead of 30-40mb of app memory after the system software, OS, etc. is installed.
That is just my opinion but it would definitely remove one of the biggest negatives many reviewers talk about. The disappearing memory because of persistant store use (have seen many times where someone says they started the BlackBerry with 30mb of memory and suddenly they only have 2mb) is my biggest issue right now.
12-01-2009 05:54 PM
rcmaniac25 wrote:The disappearing memory because of persistant store use (have seen many times where someone says they started the BlackBerry with 30mb of memory and suddenly they only have 2mb) is my biggest issue right now.
Who says that declining memory use is due to persistent storage? Declining memory use is due to regular memory usage as well -- and you can't exactly eliminate that.
I'm sure the partitioning of memory like is used on the Blackberry is for sandboxing purposes and for bolstering security (the relevance of this can be questioned, I suppose).
12-01-2009 08:07 PM
I've heard that removing and restoring the battery can improve memory usage.
However, you are pretty much stuck with what you got. I don't know about Storm 2 but what I've said about storm 1 is as is.
You can copy any memory you want to SD Flash.
Good Luck.
-D
12-01-2009 09:24 PM
I should have said "I assume" because if you don't install anything and use only one app at a time then how does the amount a available memory change? Does the memory not get freed? The only way it wouldn't get freed is if it was persistent.
Also what about the RuntimeStore? I don't think that counts as persistent memory but what if you are using a bunch of applications that use the RuntimeStore. Would the phone eventually run out of RAM? Would it cause the phone to do a garbage collection? A nagging voice in the back of my head is saying I know the answer already but I already wrote this and would like to see what others think/know and to create a concrete answer if something like this comes up again.
12-01-2009 09:53 PM
I did explain it somewhere. There are memory issues in that when you allocate memory and release it, some other app may want to allocate memory. What happens is memory fragmentation so there are gaps too small to be allocated in between other allocations so it looks like more memory is being used. You need an app like a disk fragmentation app to fix this and I don't think you can do that as I'm unsure as to how the memory internals work as it's a speecial type of flash.
Good Luck.
-D
12-01-2009 10:23 PM
Thank you, I am primarily a .NET programmer and know how that memory manager works so I find that it can't defragment the memory as odd but understandable.
12-01-2009 11:51 PM - edited 12-01-2009 11:54 PM
No, if an application does not clean up properly after itself then it will leak memory and not get freed, even when it is closed, and that will cause application memory to drop. (There are no fragmentation issues here as far as I know)
Persistent storage (ie., PersistentStore) is only a part of the equation -- you can't blame it all on one thing or the other.
As to RuntimeStore memory -- persistence is not guaranteed, and thus it shouldn't need to be put in NVRAM, so it shouldn't play a part here.
12-02-2009 02:42 AM
There is RAM there and that shouldn't be an issue, but I assure you there are memory fragmentation issues with Flash memory. Let me explain. When you write a variable that's stored in flash, it's stored in some place where it is allocated. Then, when you write it again, it isn't written in the same place. The location is changed, the old location is marked as free and a new spot in flash is written. This is because you write flash until a block is full and then you erase the entire block before it can be rewritten. Flash also has a limited number of write cycles, so you do a thing called wear levelling where you move the memory being used continuously around the flash until you've used every spot on the flash before you start writing back at the start again. This requires a special flash driver that is quite complex to manage all this. It's very similar in some ways to a disk managing driver. There are standards for flash management and some companies choose to use their own. We are not privy to the underlying management in the blackberry. However, consider it a little like a disk drive and thus it will have similar fragmentation issues as a disk drive would. Blocks are usually erased in the background during idle time as it takes time and often access to the flash part may be limited during the erase cycle.
I hope that helps. Incidentally, if you want to see what the internals of the storm look like, just search for sites that take it apart. There are one or two out there and that was where I got my best info at the time. They actually took it physically apart and you can see the part numbers. The flash type used in the storm was a Samsung type that uses a combination of NOR and NAND flash with some RAM buffers. The result is somewhere between the speed of nand and nor flash and it can execute in place (which you can't do with pure nand flash).
-D
12-02-2009 03:27 AM
Fragmentation has nothing to do with memory leakage or reduction in free memory.