When I first got my NS4G I was super impressed how fast it booted... like 20 seconds or so it seems. Now it is a lot longer after I've installed tons of stuff, I guess. But I checked using "autostarts" app and have disabled all but the bare minimum to launch at startup. Still though, my phone now takes 50 seconds to get to home screen from power on, while my fiancee's only takes 30 seconds (I'm guessing she has less stuff installed). I didn't think to time my reboot after flashing GRJ90 and rooting (and thus starting from scratch) the other night, but I'm betting it was like 20 seconds again like when I got the phone.
Any idea why it is so long after installing stuff? Any idea how to speed it up? 50 sec is still waaaaay better than my last phone. But 20 sec was just badass.
While I'm no developer, my guess is android needs to load all your apps during boot regardless of whether or not they will actively be running following start-up. Maybe it needs to scan them or run some kind of checkon the individual apps.
Deleting some apps should definitely help with the time.
I installed @dwitherell's TweakStock 1.4 on my Charge about 5 weeks ago, and I've mostly been happy with it. The one problem I kept running into was deteriorating performance over time, leading to frequent hard lockups requiring hard reboots. I'd gotten to the point where I needed to reboot the phone nearly every day. Having multiple active apps also tended to cause problems, for example Cardiotrainer + Rhapsody music.
Sometimes when the lag hit I was able to get a CPU usage report before the phone fully locked up. At such times I'd see kswapd0 eating a large portion of CPU. That suggested memory problems. I tried tweaking my OOM kill thresholds, to no avail.
This morning, based on some research, I took a look through my build.prop and noticed that this ROM's default VM heap size is a whopping 72MB. That sounded very high, compared to my previous phones where it was 24-32MB. I installed the VM Heap tool, knocked the heap size down to 48MB, and rebooted. My phone has been running as smooth as silk since, even with multiple simultaneously active apps running.
I'll keep watching to see how this holds up over time, but the difference even over a few hours is noticeable enough that I thought I'd report my findings right away. Regrettably, XDA discriminates against new members, so I can't post into the TweakStock developer thread as I would prefer. HTH!
thanks for the tip... just installed Eclipse, at its VM is 48MB.
tweakstock was running great for me though, so real problems like you said. my only problem (minor) was my Scrabble app being such a battery and data hog...
Thanks for the tip -- I had noticed this too, will give it a try. Though I'm on a different version of TweakStock I noticed the heap size is 72 here as well. Trying 48 for a while... will chime in if there's improvement.
- A
It is likely set high because it was found that increasing the VM heap size helped curb hot boots on heavily modified ROMs.
Interesting, thanks for the history @imnuts! I did encounter the hot boot issues some months back on earlier iterations of Gingerbread ROMs for the Charge. I will keep an eye out for hot boots to see if my 48Mb VM heap size is too low, or swap lag if it is still too high. Perhaps we will all have to try to find the best heap size for our usage patterns, as there may be no best one-size-fits-all setting.
Can't remember where, but I think I once read something that said 40 MB is the absolute best size to go with for a variety of reasons. For what that's worth...
Back on tweak stock.... can I just edit the build.prop or do I have to download VM heap?
Thanks!
tappin' that....
jco23 said:
Back on tweak stock.... can I just edit the build.prop or do I have to download VM heap?
Thanks!
tappin' that....
Click to expand...
Click to collapse
Just set the value in the build.prop.
jco23 said:
Back on tweak stock.... can I just edit the build.prop or do I have to download VM heap?
Thanks!
tappin' that....
Click to expand...
Click to collapse
Only change back only when you have issue. I currently using 72m since day one and it's working fine, super fast launching apps.
Fwiw stock settings are 64
Was so thrilled to see this recommendation, as I observed that my phone is really struggling to memory, and then kswapd0 kicks in. Tried to change it to 48MB, then to 64MB. Did not see any improvements. It looks like all apps get pre-loaded into memory, and once free memory hits less than ~80MB, the phone becomes sluggish. Once I kill all apps, the phone is back to normal snappy lag-free operation. Free memory at that point is around 135MB. This is even worse when I insert the phone into car dock. Re-draw takes about 5-7 seconds, swiping is about 2-3 seconds. In few moments it becomes ok, but still laggy.
No problems here
Been on TS1.4 w/ PBJ for about a month now, everything is still as snappy as day one. Thought I was having issues at one point but it turned out it was actually an app, Stitcher Radio, that was eating CPU and draining battery (even though I never launched it). I've over/under clocked with SetCPU at various times but never messed with the voltages.
Nonetheless, thanks to OP for this little tidbit, I'll remember it if I ever start experiencing problems.
ddavv said:
Was so thrilled to see this recommendation, as I observed that my phone is really struggling to memory, and then kswapd0 kicks in. Tried to change it to 48MB, then to 64MB. Did not see any improvements. It looks like all apps get pre-loaded into memory, and once free memory hits less than ~80MB, the phone becomes sluggish. Once I kill all apps, the phone is back to normal snappy lag-free operation. Free memory at that point is around 135MB. This is even worse when I insert the phone into car dock. Re-draw takes about 5-7 seconds, swiping is about 2-3 seconds. In few moments it becomes ok, but still laggy.
Click to expand...
Click to collapse
ddavv, sorry it didn't work for you. Some of the other things I've done to my Charge to help with the lag:
Changed io scheduler to bfq (from sio)
Tweaked my memory manager kill thresholds to 6,8,20,28,32,40 (WIP, YMMV!)
Removed some apps that kept heavy services in memory all the time, e.g. Accuweather & Lookout Security, and streaming media services I didn't use much (Last.fm, Slacker)
Turned off Google location services to stop the k3g_wq CPU runaway bug (this may be fixed in Google Maps > 6.4.0)
Switched to ADW.Launcher
Trimmed widgets I wasn't using frequently (down from 20 to 15)
I still do get a bit of lag after the phone has run for a while, so daily reboots are still a good idea for me - but I'm slowly improving my situation. I'm probably going to take a few hours to do a full wipe & reload once the FP1 ROMs start dropping, and be much more careful about indiscriminate app restoring from Titanium Backup this time. Good luck!
Hi All,
I know Zombi-POP is still in RC1 so I'm sure there are still quite a few issues. The issue I seem to be having is the tablet is VERY slow once you use it from sleep/sitting for a while. I'm not sure what its doing once I start using it again but it takes about 3-5 minutes to get back to hauling butt. I notice when playing a game that there is performance hit every 2 seconds. I can see the animation lagging so its very noticable and constant. Does anyone know what could be going on?
TF700T:
* ROM2SD on 64GB Sandisk 10. I partitioned it 16/43/1 EXT4. I'm staying away from F2FS since data could corrupt.
* Recommended settings put in place based on install notes on forum.
Governor:Interactive (not like I can change it anyways)
IO scheduler:noop
Thanks for the help. I would post this in the correct area but I'm not allowed to post there yet due to my newbie status .
That sounds as if you have automatic updates in the Play Store active. Turn it off.
And get rid of the FB app if you use it (acess it in browser instead). Any app that feels the need to phone home as soon as the tablet wakes up will make this lag-on-wake worse: weather apps, forum apps, mail... what have you.
For your game you could try to play with the Transition animation and Animator duration scale in Developer Options. Set them to .5 and see if that helps.
You should really give f2fs on internal a whirl. As long as we have been playing with f2fs I still have to hear from a single user who had data loss issues because of it. And anyway - if you keep sensitive data on your portable device you should have a solid backup routine in place no matter what. And if you do data loss is a non-issue
mediaserver is the issue...
I was watching the system for a while during wakeups and found that the mediaserver process is causing this slowdown. I guess its scanning the driver? I'm not sure. All I know is there is a app already created out there that kills the mediaserver process for good. I tried killing it from the terminal but it starts up right afterwards. I'll stick with EXT4 for now. The performance is great for me once that process is gone and I'm more familiar with EXT4.
Thanks!
Andy
berndblb said:
That sounds as if you have automatic updates in the Play Store active. Turn it off.
And get rid of the FB app if you use it (acess it in browser instead). Any app that feels the need to phone home as soon as the tablet wakes up will make this lag-on-wake worse: weather apps, forum apps, mail... what have you.
For your game you could try to play with the Transition animation and Animator duration scale in Developer Options. Set them to .5 and see if that helps.
You should really give f2fs on internal a whirl. As long as we have been playing with f2fs I still have to hear from a single user who had data loss issues because of it. And anyway - if you keep sensitive data on your portable device you should have a solid backup routine in place no matter what. And if you do data loss is a non-issue
Click to expand...
Click to collapse
You should really switch to internal and F2FS - there is no risk of corruption. Rom2sd doesn't play well with zombi.
Is anyone else commonly seeing "system" consume 1 - 1.2GB of RAM? When restarted, system consumes about 600MB of RAM and the phone runs smoothly. After several hours, the entire phone is almost unusably slow because Android is constantly killing and restarting applications, redrawing takes forever, and it may even take 5 to 10 seconds just to return home.
Info
kaimyn said:
Is anyone else commonly seeing "system" consume 1 - 1.2GB of RAM? When restarted, system consumes about 600MB of RAM and the phone runs smoothly. After several hours, the entire phone is almost unusably slow because Android is constantly killing and restarting applications, redrawing takes forever, and it may even take 5 to 10 seconds just to return home.
Click to expand...
Click to collapse
which apps take the most process?
what is condition of ur phone? any customization? 3rd party mods & etc?
Have u tried factory reset OR install stock firmware of another regions?
:good:
kaimyn said:
Is anyone else commonly seeing "system" consume 1 - 1.2GB of RAM? When restarted, system consumes about 600MB of RAM and the phone runs smoothly. After several hours, the entire phone is almost unusably slow because Android is constantly killing and restarting applications, redrawing takes forever, and it may even take 5 to 10 seconds just to return home.
Click to expand...
Click to collapse
phone is stock but am using google launcher. most process is consumed by facebook, followed by line.
i did wipe it before and it seemed to get better but also could have been placebo. i haven't tried installing firmware from another region mainly because i'm worried about potential radio issues.
same issues here, but happens after 1 or 2 days. possibly some memory leak bugs. have to restart my phone when it getting lag
Ever since Android announced trim support this topic seems to be ignored ever since.
It shouldnt have been.
At least on some devices manual fstrim (busybox) of any version dont work, at least not fully properly as it should.
Never did, and i highly doubt it does work with android kernel built in command thats supposed todo that on its own.
That would explain the usual performance gain after formating data poartition at least for a few days.
I testet this over the years on S2, Note3, NExus 5, nexus 9 and a few other phones.
latest tests are note 3 and nexus 9 on lineage 14.1 (droid 7.2) and oreo.
Here is the results
On Android (native app, or shell via busybox):
it says it trims, consecutive trims lead smaller sizes and at some point to "trim not required" - as it should be.
However a fter a few minutes data trims again hundreeds of megs, an hour later gigabytes
- wtf - monitoring the write activity showed nothing at all. also the battery should be drained if it writes 20gigs an hour to the sdcard constantly - something seems off.
This behaviour has been as is ever since. fstrim never seem todo much.
Now we test this under twrp on the shell.
after one trim it was imidiatly to zero (so second trim says not required)
allright fine, this is how its supposed to be...
well .... nope ... after remounting it imiditaly wants to trim 100% of the free space.
ext4 is not supposed to work like this on trim, it should always only allow untrimmed freespace (in contrast to btrfs which always trims all).
Now important to know is that fstrim is no relyable method to find out if trim is working or what your block devices does.
it could be very well trim is working as intended but reports wrongly.
However the behaviour of trimming down to little, then to zero, then growing big and fast seems to indicate otherwise.
it looks more l ike trim job marks as trimmed (while its sheduled todo that really) - and unamrk step by step later
if this is true it also means the discard mount option actually is contraproductive at best.
Resolution:
i found that switching to f2fs solves that issue.
Trims are now realistic (like 300mb after 5 hours) zero for a long time, correct sizes when you delete a bigger file and so on.
also its now incredible fast.
the massive difference on my devices between f2fs and ext4 is another indicator that trim never worked. it seems like on the first day.
f2fs is supposed to be 20% slower on reads yet i have across all devices a massive improvment, no mroe lags or stutter on ceertain operations. specially chromiun based browser became lightning fast, as in only fractions of a second loading time, compared to seconds before (which make sense considering how the cache is working all the littel files take up an insane time if you need to clear those bytes first)
oh and did i mention it works very well with encryption on?
well it does, and thers no real speed difference now beween unecrypted and encrypted.
bottom line, i doubt trim ever worked on ext4 systems, at least not on all of them.
f2fs is teh solution at least for such older devices like mine, together with oreo my old ones are back in business... watining for a samsung note with on screen fingerprint reader and no knox )