[Giant Cashew]

As I'm sure some of you have seen, there are now some apps coming out that are starting to mimic some of MeterBerry's functionality. This thread is NOT a knock on those applications. They look great and I honestly congratulate the developers.

But I do want to clear up some questions that have come up due to these new apps about MeterBerry and memory/battery usage. As is mentioned in MeterBerry's forum thread (see my signature), MeterBerry is about 150 KB in size. I have heard people say that an app of this size:

a) Wastes memory, and it's foolish to waste memory while monitoring memory.
b) Wastes battery life.
c) Taxes the CPU.

This is simply not true. Let me explain:

There is a very big difference between the installation footprint and the runtime footprint of an application. The installation footprint of an application is how much space it takes up in the application block when it is installed. The runtime footprint of an application is how much application memory it consumes while running after your device has started up.

MeterBerry has a ~150 KB installation footprint, but that doesn't mean it "wastes 150 KB" when it runs. Its runtime footprint is much smaller. And its size doesn't automatically mean it consumes a lot of battery life. A few points:

1. ~100 KB of MeterBerry's installation footprint is its icon files. These icons are data-only, and do not have any affect whatsoever on your free application memory after the device starts up.

2. MeterBerry's logs are a fixed size. They hold roughly 48 hours worth of data at the fastest update rate. The logs are allocated on startup, so they do not have any affect whatsoever on your free application memory after the device starts up. When both the battery and memory logs are completely full, they only take up a few KB of space. This has no affect on your phone's performance.

3. MeterBerry's logging feature only runs once every 15 minutes at the fastest setting. The logging takes mere microseconds, and is not "taxing on the CPU," nor does it affect battery life, as some has suggested.

4. MeterBerry has very small runtime footprint. I am an embedded software engineer with years of experience developing safety-critical software for military helicopters and jets. I wrote MeterBerry at night and over the weekends because I love Blackberries. MeterBerry has been exhaustively optimized to ensure that any application memory it uses while running is recovered by the Java garbage collector. It doesn't "leak" memory.

5. Because of its small runtime footprint, MeterBerry's affect on battery life is negligible. An application's installation footprint has nothing to do with its affect on battery life, only its runtime footprint does.

Again, it is easy to make a sweeping statement after looking at all of MeterBerry's functionality and its file size that it must use a lot of memory and battery, but this is truly not the case. Other, smaller applications claim they have an advantage because they "use less resources." Please don't buy into this. The difference is truly negligable. MeterBerry IS a small application, and is highly optimized and efficient. I hope that everyone can appreciate and understand this.

As usual, if you have any questions please feel free to e-mail me at help@meterberry.com.

[BerryNick]

It is very refreshing to read something written by someone that knows what they are talking about. There is so much rumor and misinformation posted on how application memory is used or not used or leaked or whatever.

I have not used MeterBerry, but, I now intend to give it a try.

Thanks again for your post.

[suzieque]

thanks for the info Giant Cashew! I have meterberry installed, actually since the previous 2 versions.

The bad news is I did update to the latest meterberry, the latest quicklaunch and Appworld application all the same week. One of the 3 is causing a leak which I see in the meterberry logs when my storm goes to sleep the leak begins and then seems to recover somewhat while using the device, I suspect it's Appworld so I deleted Appworld last night.

I don't understand memory leaks. Maybe you can explain what they are caused by and how to help diagnose a memory leak using meterberry?

thanks for the great app!

[Giant Cashew]

thanks for the info Giant Cashew! I have meterberry installed, actually since the previous 2 versions.

The bad news is I did update to the latest meterberry, the latest quicklaunch and Appworld application all the same week. One of the 3 is causing a leak which I see in the meterberry logs when my storm goes to sleep the leak begins and then seems to recover somewhat while using the device, I suspect it's Appworld so I deleted Appworld last night.

I don't understand memory leaks. Maybe you can explain what they are caused by and how to help diagnose a memory leak using meterberry?

thanks for the great app!

There have been lots of reports that the new App World application has been causing excessive memory usage.

The term "memory leak" is misunderstood. From my FAQ on the MeterBerry website:

--------------------------------------------------

Java uses automatic garbage collection to manage memory. Applications create memory objects, and the Java garbage collector recovers memory objects that are no longer in use. The garbage collector runs only when it is convenient, usually when the handheld is idle or in an emergency when memory is needed and none is available. Because of this, it is typical for the memory objects created by an application to not be recovered for many minutes or even hours.

So, it is completely normal for the device's free application memory to fluctuate up and down.

It is the responsibility of applications to remove references to memory objects they no longer need. This signals to the garbage collector that the memory used by those objects can be recovered and used for something else. A "memory leak" in the context of a Blackberry device can occur when an application repeatedly creates memory objects and doesn't remove references to those objects when it no longer needs them.

If your free memory drops a certain amount after you restart your phone, this does not automatically mean you have a memory leak. This is completely normal as the Blackberry OS caches things in application memory, just like your computer does with its RAM. However, if your free memory dwindles to a very low value and never increases unless you restart your phone, you probably do have a true memory leak.

[The Antagonist]

Thanks, GC. It's refreshing to see logic prevail in the forums on occasion. I've used MeterBerry since release and will never go without it now. The latest round of updates including rotating displayed icon, threshold warnings, and quickpull-like reset function are second to none. Thanks for a great product that has no noticeable effect on my device memory or battery life, but provides an awesome interface with valuable information.

[zazzified]

Very cool of you to take the time to write this up and settle it.

[phrehnck]

There have been lots of reports that the new App World application has been causing excessive memory usage.

The term "memory leak" is misunderstood. From my FAQ on the MeterBerry website:

--------------------------------------------------

Java uses automatic garbage collection to manage memory. Applications create memory objects, and the Java garbage collector recovers memory objects that are no longer in use. The garbage collector runs only when it is convenient, usually when the handheld is idle or in an emergency when memory is needed and none is available. Because of this, it is typical for the memory objects created by an application to not be recovered for many minutes or even hours.

So, it is completely normal for the device's free application memory to fluctuate up and down.

It is the responsibility of applications to remove references to memory objects they no longer need. This signals to the garbage collector that the memory used by those objects can be recovered and used for something else. A "memory leak" in the context of a Blackberry device can occur when an application repeatedly creates memory objects and doesn't remove references to those objects when it no longer needs them.

If your free memory drops a certain amount after you restart your phone, this does not automatically mean you have a memory leak. This is completely normal as the Blackberry OS caches things in application memory, just like your computer does with its RAM. However, if your free memory dwindles to a very low value and never increases unless you restart your phone, you probably do have a true memory leak.

yea...I'm afraid app world's mem usage is gonna start another good ole fashioned crackberry 3rd party app memory leak witch hunt...

[Giant Cashew]

yea...I'm afraid app world's mem usage is gonna start another good ole fashioned crackberry 3rd party app memory leak witch hunt...

I wouldn't be surprised if the App World uses a lot of memory while running because it is very graphical and uses a lot of network traffic. Whether it has a true memory leak however is a different story. I haven't had enough time to play with it to figure that out yet.

[Simonintx]

thanks for the info Giant Cashew! I have meterberry installed, actually since the previous 2 versions.

The bad news is I did update to the latest meterberry, the latest quicklaunch and Appworld application all the same week. One of the 3 is causing a leak which I see in the meterberry logs when my storm goes to sleep the leak begins and then seems to recover somewhat while using the device, I suspect it's Appworld so I deleted Appworld last night.

I don't understand memory leaks. Maybe you can explain what they are caused by and how to help diagnose a memory leak using meterberry?

thanks for the great app!

I have the same issue. I deleted App World and the leak was still present so I ended up re-installing it. The leak doesn't seem to affect performance, it is just disconcerting. Meterberry is a great app but I think it makes me a little OCD about my memory and battery usage.

[Giant Cashew]

I've also received several questions from people asking what exactly is "application memory," and why is there such a small amount of it? Here is the answer:

The Storm has 1 GB of internal flash, or device memory. 128 MB of that flash is allocated as application space, the other 872 MB is allocated as data space. The Storm also has 128 MB of traditional RAM. These memory spaces are used as follows:

1. When they are running, the OS and applications both use the 128MB of traditional RAM like your computer does. Temporary, volatile storage.

2. All applications are stored in the application space. Whatever room is free in the application space is used by the OS for paging when your phone is running, similar to what your computer does with its hard drive and swap file. Applications can only be stored and run from the application space.

3. The data space is used for an internal file system, as well as storage of things like pictures, ring tones, etc. You cannot store and run applications from the data space.

When you go to Options -> Memory, the "Application Memory" entry refers to the free space in the application block of the internal flash.

So, when you install applications the free space in the application block decreases. And because the application block is also used for paging, the free space fluctuates over time as you use your phone.

I would hypothesize that the reason RIM doesn't display the free RAM under Options -> Memory is because the RAM is used by the OS in addition to applications. It wildly fluctuates all over the place as the phone is running, and doesn't give you any real measure of what's going on. But if an application has a true memory leak as is described above, you would be able to detect it by looking at the free application memory. And of course your free application memory also tells you how much room you have left for applications.

[BerryNick]

Please put this on the MeterBerry site. It is a great repository of information on the whole issue of Application Memory is it applies the Storm.

I did purcahse and load MeterBerry today and am very impressed with its functionality. Any future additions such as scheduled Resets will only enhance the product.

[Transfigured]

Thank you for meterberry & your post.

I just found out my 10 hr overnight battery discharge was 14%. Would someone tell me if that is in the normal range? I have google maps & bb weather, but doubt they're the cause.

UPDATE: tested out a couple theories & turns out if u shut phone off in-between logs then at next start-up, log shows ur usage b4 turning off plus what should be minimal overnight battery discharge. That is why my log read 14%!!

[Giant Cashew]

Thank you for meterberry & your post.

I just found out my 10 hr overnight battery discharge was 14%. Would someone tell me if that is in the normal range? I have google maps & bb weather, but doubt they're the cause.

I typically charge my phone at night, so I can't say exactly. Perhaps someone else can chime in.

But 14% sounds reasonable for 8+ hours of idle time.

[Giant Cashew]

Please put this on the MeterBerry site. It is a great repository of information on the whole issue of Application Memory is it applies the Storm.

I did purcahse and load MeterBerry today and am very impressed with its functionality. Any future additions such as scheduled Resets will only enhance the product.

Thank you. We are hard at work on adding requested features, and we will release them as soon as they're ready.

I have added the above words about application memory to the MeterBerry FAQ.

[jj1000]

I've also received several questions from people asking what exactly is "application memory," and why is there such a small amount of it? Here is the answer:

The Storm has 1 GB of internal flash, or device memory. 128 MB of that flash is allocated as application space, the other 872 MB is allocated as data space. The Storm also has 128 MB of traditional RAM.

How are these memory spaces used?

1. The OS and applications both use the 128MB of traditional RAM like your computer does.

2. All applications are stored in the application space. Whatever room is free in the application space is used by the OS for paging when your phone is running, similar to what your computer does with its hard drive and swap file. You cannot store and run applications anywhere else besides the application space. In hindsight, I think only 128 MB is low, but there is nothing we can do about it.

3. The data space is used for an internal file system, as well as storage of things like pictures, ring tones, etc. You cannot store and run applications from here.

When you go to Options -> Memory, the "Application Memory" entry refers to the free space in the application block of the internal flash, what I'm referring to as the "application space".

So, when you install applications the free space in the application block decreases. And because the application block is also used for paging, the free space fluctuates over time as you use your phone.

I believe the reason RIM doesn't display the free RAM under Options -> Memory is because the RAM is used by the OS in addition to applications. It wildly fluctuates all over the place as the phone is running, and doesn't give you any real measure of what's going on. But if an application has a true memory leak as I described above, you would be able to detect it by looking at the free application memory. And of course your free application memory also tells you how much room you have left for applications.

This is all great info but is it possible since we all have micro sd cards to store pics and etc. on to write a program to reallocate the 872 to a smaller size and increase the 128. just asking thanks for the info.

[Giant Cashew]

This is all great info but is it possible since we all have micro sd cards to store pics and etc. on to write a program to reallocate the 872 to a smaller size and increase the 128. just asking thanks for the info.

This is not possible with a 3rd party application. In theory, RIM would be able to change the allocation in a future OS. But until then, we are stuck with what we've got.

[jj1000]

thanks i figured as much but we all you great programmers out there i was still hoping it was possible.

[Ultrafied]

GC - great job. I got MeterBerry when it first came and has helped me understand the BB a little. I have noticed memory fluctuate considerable with your tool. It was interesting to note that memory could be as low as 15mgb just sitting in my holster. I would got the browser, surf and get out at which time I would not have 19-20mgb. Your explanation has helped me understand why and your tool is amazing!! I always list it as my number 1 must have app.

[MadCowStorm]

Great thread and killer app cashew.

Thanks.

Posted from my CrackBerry at wapforums.crackberry.com

[cray1000]

As I'm sure some of you have seen, there are now some apps coming out that are starting to mimic some of MeterBerry's functionality. This thread is NOT a knock on those applications. They look great and I honestly congratulate the developers.

But I do want to clear up some questions that have come up due to these new apps about MeterBerry and memory/battery usage. As is mentioned in MeterBerry's forum thread (see my signature), MeterBerry is about 150 KB in size. I have heard people say that an app of this size:

a) Wastes memory, and it's foolish to waste memory while monitoring memory.
b) Wastes battery life.

This is simply not true, and is just clever marketing. Let me explain:

There is a very big difference between the installation footprint and the runtime footprint of an application. The installation footprint of an application is how much space it takes up in the application block when it is installed. The runtime footprint of an application is how much application memory it consumes while running after your device has started up.

Just because MeterBerry is ~150KB in size doesn't mean it is "wasting 150 KB" when it runs. That is nonsense. And its size doesn't automatically mean it consumes a lot of battery life. Let me explain:

1. ~100 KB of MeterBerry is its icon files. These icons are data-only, and do not have any affect whatsoever on your free application memory after the device starts up.

2. MeterBerry's logs are not stored in application memory, and are instead stored in persistent memory on the internal device memory. So, like the icon files, the logs do not have any affect whatsoever on application memory after startup.

3. MeterBerry has VERY small runtime footprint. I am an embedded software engineer with years of experience developing safety-critical software for military helicopters and jets. I wrote MeterBerry at night and over the weekends because I love Blackberries. MeterBerry has been exhaustively optimized to ensure that any application memory it uses while running is recovered by the Java garbage collector. MeterBerry does what it needs to do, marks the memory it used as no longer needed so it will be recovered, and gets out. It doesn't "leak" memory.

4. Because of its small runtime footprint, MeterBerry's affect on battery life is negligible. An application's installation footprint has nothing to do with its affect on battery life, only its runtime footprint does.

Again, it is easy to make a sweeping statement after looking at all of MeterBerry's functionality and its file size that it must use a lot of memory and battery, but this is truly not the case. I hope that everyone can appreciate and understand this.

As usual, if you have any questions please feel free to e-mail me at help@meterberry.com.

i am confused, your saying the app doesnt use the app memory, but when you install it its installed in app memory, and the persistent store goes in app memory, so wouldnt your app use app memory?

[Giant Cashew]

i am confused, your saying the app doesnt use the app memory, but when you install it its installed in app memory, and the persistent store goes in app memory, so wouldnt your app use app memory?

I apologize if I wasn't clear. I didn't say MeterBerry "doesn't use app memory". It is more complicated than that, which is what my original and subsequent posts explain. Any application you install will cause your baseline free application memory to decrease, because that is where applications are stored.

But some applications will cause your free application memory to decrease significantly further after your phone has started, and some have leaks that eat all your memory. MeterBerry is not one of them.

Please take a look at my post on the first page which discusses how application memory is used by the phone and OS. Also, the persistent store is not stored in the application space, it is stored in the data space in internal device memory.

[localbiz]

Thanks for the great app, and taking the time to explain things. I currently have logmaid also on my Storm, do you think I need this if I have MeterBerry?

[Giant Cashew]

Thanks for the great app, and taking the time to explain things. I currently have logmaid also on my Storm, do you think I need this if I have MeterBerry?

MeterBerry currently doesn't do any memory "cleaning" like LogMaid does. However, in the future, I hope to add some memory cleaning functionality. It seems like it would fit very well with the rest of MeterBerry's features.

[mike240se]

Please take a look at my post on the first page which discusses how application memory is used by the phone and OS. Also, the persistent store is not stored in the application space, it is stored in the data space in internal device memory.

its pretty clear your talking about my app with this thread and thats cool, but your making it sound like i am wrong in saying my app uses less resources and i dont think i am. some of your claims are incorrect like the one above.

your app uses the persistent store as you have stated on a regular basis to log your battery and memory usage. either its got to be stored in memory or in the persistent store and your saying its the persistent store and that it is not stored in the application space, but here are the facts:

taken from rim's website, here is the link:
BlackBerry - BlackBerry | Wireless Handheld Devices, Software & Services from Research In Motion (RIM)

Considering the facts

Creating an application for the BlackBerry handheld requires a developer to consider many factors not present in a conventional system, such as:

* Persistent store objects live in a finite amount of flash memory that is shared with the operating system, applications for BlackBerry, third-party applications, and user data.
* The data transfer rates to and from flash memory is slower than conventional memory (RAM).
* Reading and writing to flash memory forces the CPU to work harder, which in turn compromises battery life.

as you can see, persistent store data shares with app memory and is stored in flash memory. you can also see that reading and writing to flash memory forces the cpu to work harder and consumes more battery.

i am not saying your app is bad at all, i am just saying mine is a smaller alternative that does one thing and does it in a small 10-12k footprint. if someone wants logs and doesnt mind taking the small hit in battery and memory then yours might be their choice, if they care about every shred then they might prefer mine. i dont think there needs to be some war, because they are two seperate apps that will suit two different types of users.

[Giant Cashew]

its pretty clear your talking about my app with this thread and thats cool, but your making it sound like i am wrong in saying my app uses less resources and i dont think i am. some of your claims are incorrect like the one above.

your app uses the persistent store as you have stated on a regular basis to log your battery and memory usage. either its got to be stored in memory or in the persistent store and your saying its the persistent store and that it is not stored in the application space, but here are the facts:

taken from rim's website, here is the link:
BlackBerry - BlackBerry | Wireless Handheld Devices, Software & Services from Research In Motion (RIM)





as you can see, persistent store data shares with app memory and is stored in flash memory. you can also see that reading and writing to flash memory forces the cpu to work harder and consumes more battery.

i am not saying your app is bad at all, i am just saying mine is a smaller alternative that does one thing and does it in a small 10-12k footprint. if someone wants logs and doesnt mind taking the small hit in battery and memory then yours might be their choice, if they care about every shred then they might prefer mine. i dont think there needs to be some war, because they are two seperate apps that will suit two different types of users.

Nothing in the article you posted disproves what I said. The application and data blocks are both in flash memory. RIM doesn't publish the inner workings of the OS's memory management, but it is generally agreed upon by Blackberry developers that persistent objects are stored in the data block, not the application block. BOTH of these are in flash memory, which I believe is what RIM is referring to. But creating persistent objects does not cause the "application memory" value to decrease.

MeterBerry's logs are a fixed size, not infinite. Old entries are thrown away. If all of the logs are full they take up a few KB of space. Do you seriously think that has any affect on the phone's performance?

You're REALLY splitting hairs here. The point of this thread was to point out that MeterBerry's affect on memory usage and battery life is negligible. The hundreds of people who have purchased it can attest.

I do not know anything about the runtime footprint of your application because I didn't write it. But just because it has a 10 KB installation footprint doesn't mean its runtime footprint is also small. I never stated that I thought your application did not use less resources than MeterBerry. I wouldn't make that statement because I don't know anything about the inner workings of your application. My point is that the difference is negligible. It's like saying people prefer to send one text message instead of two because it uses less resources.

There is no need to have a war. This thread is about MeterBerry. I was only attempting to answer questions about its resource usage. I congratulate you on the release of your application. The more applications this community has, the better.