Related
Hi all,
i have read all i can find on the forum on this topic and i wanted to ask is a specific procedure existed for determining a memory leak (if i have one!) i find the gwes.exe file starts at 12mb at boot and generally increases untill a soft reset. it can reach 18mb. whilst i am not sure if this effects performance it causes my memory usage to rise constantly for no reason i can determine!
my setup - rom miri wm6.5 v26.3 - premium WITHOUT manilla
interface - spb mobile shell
dialer - phone ex
not much else
any ideas hints kindly recieved!
regards
Mat
lemat1 said:
i have read all i can find on the forum on this topic and i wanted to ask is a specific procedure existed for determining a memory leak (if i have one!) i find the gwes.exe file starts at 12mb at boot and generally increases untill a soft reset. it can reach 18mb. whilst i am not sure if this effects performance it causes my memory usage to rise constantly for no reason i can determine!
Click to expand...
Click to collapse
GWES memory consumption growth is as natural as gravity and it happens to improve performance. This happens because it is smart enough to keep resources in fast RAM so that next time they will not be loaded from (comparatively slow) flash memory. Basically this is the point in having RAM and the reason why you paid for it - it has to be loaded with stuff to make things faster. This sport of freeing RAM is just ridiculous in most cases (although not always, of course). You pay for it and then don't use.
Secondly, what you describe is not a memory leak. A memory leak is a situation of uncontrolled memory usage growth (if your GWES gradually ate all available memory to a point where device would crash that would be a memory leak). In general, there's nothing wrong with applications consuming more and more RAM as they work as long as they can free this RAM on demand. See for yourself: on your PC, load a memory-hungry application such as a web browser, note how much RAM it uses initially. Then use it for a while, RAM consumption will grow. Then minimize it and see how RAM usage drops dramatically. Even if an application uses half of all RAM it doesn't mean that this RAM isn't available for other programs when needed. When it's not needed, why not use it?
I have noticed behaviour pointing to a memory leak on the X10 - After turning the phone on, I get less and less free memory after running ATK - over 110 MB right after turning the phone on to ~70 MB after 24+ hours.
The phone is heavily modified/customized, so it may not be an SE sw bug (ADW, Smart Keyboard, handcent, k9, etc...)
What's the best process tool you can recommend to look into this?
Let the phone handle the memory. dont worry.
+1 on that. Android its linux based and us meant to work like that. Empty memory is wasted memory.
-------------------------------------
Sent from my X10i
Android may be Linux based, but if *after killing all idle processes* memory is systematically dwindling, that means/may mean that one or more of these processes is allocating memory which it is then NOT being released - either by the process (more probable) or the system itself (less probable).
In other words, for the same set of running processes/applications , the memory usage should *not* systematically go up over time.
Linux itself has no automatic GC. Android does (Dalvik VM), but it takes some care from developers for that to work properly - no "loose" pointers to unused but still-referenced data, etc....
acmbc said:
Android may be Linux based, but if *after killing all idle processes* memory is systematically dwindling, that means/may mean that one or more of these processes is allocating memory which it is then NOT being released - either by the process (more probable) or the system itself (less probable).
In other words, for the same set of running processes/applications , the memory usage should *not* systematically go up over time.
Click to expand...
Click to collapse
I disagree, as processes are used/exercised the kernel will allocate the memory they need, after switching on the phone the processes are idle and occupy a small amount of memory. As they are used the process size will grow in main memory as they store or cache common data used by the process. That is why applications such as facebook may be slower at start off as the data needs to be supplied, once this data is cached it will run much faster as the data is already in main memory.
Linux/Android works on the principle that it's a waste not to use as much memory as possible.
Not to get into a GC flame war here: The principle you mention is right, its just that after one KILLS these processes (facebook for example) ALL OF the memory allocated by facebook should be relinquished to the system (ergo, appear as free).
I.e. if I start up my phone, and just have processes A B and C running and have lets say 120 MB free, and after using the phone for a while kill everything and *restart* ONLY processes A B and C, then I should have 120 MB free. At least tendentially (may have a different set of resident libs at the 1st and 2nd points in time, some other minor stuff may be different, etc..). However, I find that doing this over and over results in less and less free memory being available as time passes.
I am not saying I am *right* but a good process inspection tool would help to ascertain what is going on.
acmbc said:
Not to get into a GC flame war here: The principle you mention is right, its just that after one KILLS these processes (facebook for example) ALL OF the memory allocated by facebook should be relinquished to the system (ergo, appear as free).
I.e. if I start up my phone, and just have processes A B and C running and have lets say 120 MB free, and after using the phone for a while kill everything and *restart* ONLY processes A B and C, then I should have 120 MB free. At least tendentially (may have a different set of resident libs at the 1st and 2nd points in time, some other minor stuff may be different, etc..). However, I find that doing this over and over results in less and less free memory being available as time passes.
I am not saying I am *right* but a good process inspection tool would help to ascertain what is going on.
Click to expand...
Click to collapse
Wrong.. it should NOT be returned to the system.. but it should be marked as "disposable" IF another process wants to use it. That is the way linux usually do.. That is why the "Free"-value is misleading. As the "Free"-value is not the sum of "Free" and "Cached" values. when you "unload" a lib it is not completely removed from memory, it is just marked as "cached" instead. Saving tremendous ( ) amount of battery and time when, if, the user wants to use it again before overwritten by another memory-hungry application..
Regards // OwL
does all this mean we don't really need advanced task killer?
or does the advanced task killer kill the cpu process? ( as a result longer battery life)
robbyf66 said:
does all this mean we don't really need advanced task killer?
or does the advanced task killer kill the cpu process? ( as a result longer battery life)
Click to expand...
Click to collapse
advanced task killer kills the application itself, so that nothing more is executed by that application thread(s). wether dependent libraries are kept loaded or not does not affect battery time when not used. Advanced task killer does not actually unload any libraries it only kills the process.
I personally hardly never use advanced task killer, as it is not needed as long as you make sure to run applications that does not keep the phone from going into sleepmode. Those programs are just simply bad coded.. I instead have a CPU-meter application in the task-bar and if I see that the CPU-time is extensivly used after the application has been put to background, then I might use a taskkiller to stop the bad application. But that scenario is rare... I usually get 50h+ of battery time per charge, whatever I do with it.
Regards // OwL
Hey guys . i found this app in the android market ---Memory Booster ... it is much better than the advanced task killer ! and it can free a lot of ram ! just try it out once ..i freed 86 mb ram in one go ...i had 55 mb available ..and after using this i got 141 ram total free ! just type memory booster in android market search ..and download the first one !
Info -
Description
Memory Booster is a powerful mobile Memory & RAM boosting tool specially designed for Android smartphone users. It is a handy memory optimizer tool that will keep your Android smartphone running faster and efficiently. It increases your cell phone's performance by making more memory available for both your applications and the mobile system.
Memory Booster is designed to tackle the difficult but crucial problem of memory management for Android smartphone users. Memory is the most precious resource in your smartphone; when it becomes low, your cell phone will slow down severely or crash. If the mobile system cannot handle your memory properly by itself, your smartphone will slowly lose memory over time and bring you to a critical state. Memory Booster solves these problems by reclaiming lost memory for your programs. It helps your smartphone run at optimum speed by efficiently defragmenting your smartphone's memory, recovering memory leaks from poorly behaved application, flushing unused libraries temporarily out to disk and so on. By all this optimization tricks your favorite applications and games will run faster and efficiently with Memory Booster running in the background.
Memory Booster is optimized for all series of Android OS smartphones, which can monitor your mobile system in the background, freeing resources when needed. It uses many advanced features to keep your smartphone running at optimum speed. But more importantly, it's designed with all users in mind; whether you're a power-user or a novice, Memory Booster will give you the features you want without confusing or limiting you.
Praised by both individual users and large companies alike, Memory Booster is the best utility of its type available. Memory Booster from DownloadAndroid.Info, represents the best technical and design efforts as Android system tool, to bring you a technically superior, yet easy-to-use memory management utility.
Product Features:
•Real-time Smartphone Memory Status Report & Monitor Memory Booster gives you professional, easy-to-read status report on your smartphone's memory usage. A live chart demonstrates your total available memory and current memory usage. Memory Booster makes it easy to see how well your smartphone is performing, and whether your system is overloaded.
•Setting Your Performance Target
Using Memory Booster's Settings function, you can boost phones by setting performance goal fits your profile. Memory Booster will work to keep your memory at desired levels, and act immediately if memory drops below critical level.
•One-click Quick Memory Boosting
In addition to monitoring and reclaiming your memory automatically, Memory Booster allows you to boost your memory manually. By using the Quick Boost feature, you can observe Memory Booster reclaiming more memory for your system. In the mean time, Quick Boost will smartly remember the settings that work best for your smartphone.
•Auto-boosting in the Background
Your memory is the most important resource on your smartphone, and how it is used can drastically affect performance. With Auto-boosting feature, Memory Booster can run in the background and automatically reclaim unused memory on your Smartphone. It oversees the allocation of memory resources through its unique cache management technique.
•Android system crash protection
The majority of smartphone crashes come when system resources are inadequate. Memory Booster automatically watches and cleans up your Android's system memory when it reaches a critical point. By using Memory Booster, you don't need to know anything about your smartphone system; Memory Booster will provide all the technical know-how.
•And there is more.
Other features include embedded Advanced Task Manager, Whitelist Manager, Boost Level Manager & Memory Boost Log, which allow you to manually quit the running applications safely, to protect items from being killed during Memory Booster's boost operation, to easily adjust Memory Booster's boost strength according to users' demands, and manually check Memory Booster's boosting history to trace the effectiveness it improves your smartphone's performance.
will try bro! i am from new delhi too
Uh... the HD2 has 576mb (when using Tmob radio) of ram, and assuming the android builds can access it all, that means we *don't* need 3rd party memory managers.
Secondly, Android always tries to use up as much memory as possible for caching for a smoother UI experience, so having as much "free memory" as possible is pointless. In fact, using "memory managers" that go and kill everything might actually make your phone MORE unstable, not less.
Thirdly, the inbuild Android memory manager is already very efficient - it *automatically* kills apps that aren't used in the background. If you want to tweak it to be more aggressive at killing unneeded apps to save battery life, more useful apps would be AutoKiller and Auto Memory Manager.
EDIT: Both of those apps are free also.
OPs app is a BS app like internet boosters. hardware is like it is and you dont "boost" it
Hi guys,
I find myself, yet again, having to explain to users how linux and android manages ram.
Most users seem to think that more free ram is better. They couldn't be more wrong.
This article explains the concept in layman's terms so nobody should be confused or left doubting.
So there we go, I'll refer to this article and I hope you all do too if you see stupid remarks here in the forum regarding free ram.
Have fun reading
Quote
Linux memory consumption concept
Linux memory consumption concept is all about efficiency. The system’s RAM is a resource that is meant to be used; 100% of it (if possible), all the time (if possible).
Linux utilizes unused RAM to cache data and filesystem meta-data from slower storage devices (Flash or disk) because fetching the information from the RAM is much quicker: There are no bottlenecks such as slow physical media, slow buses or device clocks, and not decompression is required.
Assuming there are no memory leaks, the reason that memory report tools report low amount of free memory is because the RAM is considered to be wasted if it isn’t used. This concept may require some time to digest, because conventional thinking may lead to the conclusion that an efficient system is a system with a lot of free memory. This is not entirely correct. In Linux case, the kernel tries to utilize the most of the RAM to improve the system performance. Keeping the cache means that if the kernel or a task needs the same data again, there’s a good chance it will still be in the fast cache in memory.
Conclusion: less free ram = more cached process/application = better multitasking.
Some heavyweight app need lot of free memory, but in the daily usage better if you NOT use s*perch*rger or any similar script to get more free ram.
A typical bug with systems what have lot of free ram: when a call arrive, you need to wait several seconds to see the caller name, because the contacts app killed to get more free ram, and need to reload the app, open the contacts database, etc...
Sent from my E15i using xda app-developers app
pilu1978 said:
Conclusion: less free ram = more cached process/application = better multitasking.
Some heavyweight app need lot of free memory, but in the daily usage better if you NOT use s*perch*rger or any similar script to get more free ram.
A typical bug with systems what have lot of free ram: when a call arrive, you need to wait several seconds to see the caller name, because the contacts app killed to get more free ram, and need to reload the app, open the contacts database, etc...
Sent from my E15i using xda app-developers app
Click to expand...
Click to collapse
i have a lot of free ram and still doesn't have any problem with call delay or any other problem, I don't even use any ram script or any other script ,so in my rom I can enjoy when I use heavyweight app's or when I use a daily APPs
All this information is an overkill for the original discussion and it actually misses the most important point. Here's why.
The number reported by most users as free RAM is not free at all. When most users refer to the amount of free ram in a particular ROM, they're refering to the number reported in Running Apps. That memory is not free memory. And that's the most important point.
You don't read guys reporting the amount of free RAM memory while executing the free command in terminal.
It's true that the "running apps" doesn't report the true amount of free ram..
Terminal Emulator - type su then type free . I think that is the true amount of ram.
Sent from my Nexus 7 while being Paranoid .
Mockingbird said:
Terminal Emulator - type su then type free . I think that is the true amount of ram.
Sent from my Nexus 7 while being Paranoid .
Click to expand...
Click to collapse
Yeah that's right to a certain point since android grabs as much ram as it can.. Doesn't mean the remaining ram is all that's free though..
Quote
Memory management
Since Android devices are usually battery-powered, Android is designed to manage memory (RAM) to keep power consumption at a minimum, in contrast to desktop operating systems which generally assume they are connected to unlimited mains electricity. When an Android app is no longer in use, the system will automatically suspend it in memory - while the app is still technically "open," suspended apps consume no resources (e.g. battery power or processing power) and sit idly in the background until needed again. This has the dual benefit of increasing the general responsiveness of Android devices, since apps don't need to be closed and reopened from scratch each time, but also ensuring background apps don't waste power needlessly.
Android manages the apps stored in memory automatically: when memory is low, the system will begin killing apps and processes that have been inactive for a while, in reverse order since they were last used (i.e. oldest first). This process is designed to be invisible to the user, such that users do not need to manage memory or the killing of apps themselves.] However, confusion over Android memory management has resulted in third-party task killers becoming popular on the Google Play store; these third-party task killers are generally regarded as doing more harm than good.
CtrlAltDelIrl said:
Memory management
Since Android devices are usually battery-powered, Android is designed to manage memory (RAM) to keep power consumption at a minimum, in contrast to desktop operating systems which generally assume they are connected to unlimited mains electricity. When an Android app is no longer in use, the system will automatically suspend it in memory - while the app is still technically "open," suspended apps consume no resources (e.g. battery power or processing power) and sit idly in the background until needed again. This has the dual benefit of increasing the general responsiveness of Android devices, since apps don't need to be closed and reopened from scratch each time, but also ensuring background apps don't waste power needlessly.
Android manages the apps stored in memory automatically: when memory is low, the system will begin killing apps and processes that have been inactive for a while, in reverse order since they were last used (i.e. oldest first). This process is designed to be invisible to the user, such that users do not need to manage memory or the killing of apps themselves.] However, confusion over Android memory management has resulted in third-party task killers becoming popular on the Google Play store; these third-party task killers are generally regarded as doing more harm than good.
Click to expand...
Click to collapse
Certenly you explain the subject very good. It is my first time to understood. Thanks!
mikekgr said:
Certenly you explain the subject very good. It is my first time to understood. Thanks!
Click to expand...
Click to collapse
Certainly you didn't care enough about the subject before. Otherwise you would have found the same information in Wikipedia: http://en.wikipedia.org/wiki/Android_(operating_system)#Memory_management .
Unless CtrlAltDelIrl edited that article...
Fortun said:
Certainly you didn't care enough about the subject before. Otherwise you would have found the same information in Wikipedia: http://en.wikipedia.org/wiki/Android_(operating_system)#Memory_management .
Unless CtrlAltDelIrl edited that article...
Click to expand...
Click to collapse
Always these days the same problem: all information exist somewwhere but it is not very easy to "locate" the information required!
I am a beginner developer and I am sure I have a memory leak in my android application. When I open my app for the first time and check the heap size using DDMS tool from Eclipse it shows 4.5 MB. With every new opening of my app (close and reopen it) the heap size is increasing until it reaches 5.8 MB and then it settles at this size going up or down just a little bit. I also see that the amount of allocated objects increases from 44k to 60k. That is crazy I guess. But why it stops increasing at that particular point of memory (5.8 MB) and amount of objects (60k)? Furthermore, for some reason Android Application Manager's "Cached background processes" section shows that my app memory consuption increases from 10 MB to 24 MB and settles there. Why do these numbers differs from what DDMS shows? Anyway, these two tools show the same behaviour: that is with every opening my app's memory is increasing. I have tried setting all my instance variables to null in onDestroy() methods of my every activity or fragment but it didn't help. What else can I do?
Sent from my GT-I9300 using XDA Free mobile app
Maceee said:
I am a beginner developer and I am sure I have a memory leak in my android application. When I open my app for the first time and check the heap size using DDMS tool from Eclipse it shows 4.5 MB. With every new opening of my app (close and reopen it) the heap size is increasing until it reaches 5.8 MB and then it settles at this size going up or down just a little bit. I also see that the amount of allocated objects increases from 44k to 60k. That is crazy I guess. But why it stops increasing at that particular point of memory (5.8 MB) and amount of objects (60k)? Furthermore, for some reason Android Application Manager's "Cached background processes" section shows that my app memory consuption increases from 10 MB to 24 MB and settles there. Why do these numbers differs from what DDMS shows? Anyway, these two tools show the same behaviour: that is with every opening my app's memory is increasing. I have tried setting all my instance variables to null in onDestroy() methods of my every activity or fragment but it didn't help. What else can I do?
Click to expand...
Click to collapse
Are you really sure you have such a leak? Usually it happens on rotation or so and it keeps on increasing, using far more memory than your 5.8 megs. If you quit your app with the home button (instead of back) Android still keeps a lot of its data in memory so it is faster to be reopened. It still depends on what your app is doing, so releasing any unneeded receivers or caches is still a good thing to do, but in your case an increase of just 1.3MB is not significant enough to really worry about it. I don't know what the Android Application Manager is showing since I haven't used it yet.
SimplicityApks said:
Are you really sure you have such a leak? Usually it happens on rotation or so and it keeps on increasing, using far more memory than your 5.8 megs. If you quit your app with the home button (instead of back) Android still keeps a lot of its data in memory so it is faster to be reopened. It still depends on what your app is doing, so releasing any unneeded receivers or caches is still a good thing to do, but in your case an increase of just 1.3MB is not significant enough to really worry about it. I don't know what the Android Application Manager is showing since I haven't used it yet.
Click to expand...
Click to collapse
Well, I wouldn't worry if that 5.8 MB had gone down after I quit my app pressing back button, but it hadn't, so it keeps me thinking I have a memory leak. And yes, it keeps on increasing on rotation too, because the activity is recreated. It doesn't increase only when I close and open my app using home button because activity isn't recreated then. By the way, I use FragmentPagerAdapter for ViewPager and CursorAdapter for ListView. Maybe one of these could be the cause. Thank you.
Sent from my GT-I9300 using XDA Free mobile app