After I do a fresh install of cromi on my tablet, it's just excellent, fluid and smooth. After a while, the performance seems to detoriate. It has done so for about every version I tried and the same goes for my phone (An i9300 running slimkat). So my question is this: What makes an android device inherently slower? Is there a way to see what apps may slow down the performance?
That is a very good question...:good: I have the same question but I can not find a solid answer for it. I hope that some developers or experts can give us a good definition of it...
This is what I know but I may be totally off and wrong, haha..
When you first install the new ROM, all your partitions are new and clean. When you write something to your data partition, it is most of the case, it just writes data to a clean blocks without erasing the blocks. After a while, most of your blocks are dirty even though they are unused or available for writing. This is the part that users see the degradation. When a new data is writing to the available and dirty blocks, first the kernel has to erase the block before writing to it. The erase process takes a lot longer than the write process according to my research...:crying: On our tf700, writing to the internal sd or mmc is very slow already. On top of that, the erasing process has to be done before writing the new data to your internal sd. If you do the math, the performance of the writing will degrade more than twice comparing the new installation..:crying: I believe that google noticed this issue so they implemented the fsTRIM on the newer kernel source to tackle this problem..:good:
However, when you are using the fsTRIM, you have to sacrifice some slightly performance loss and you don't notice performance degradation over time.. During the normal usage, I can not tell the differences if the fsTRIM is on or off but I did see the small performance loss with a bench test..
In short, I know both _that and hund's kernel support the fsTRIM but it is disable as a default. You can try to enable it to see if it is solving your degraded problem....Good luck...:fingers-crossed:Another method is to use the lagfix manually once a week or more frequently...
sbdags
Inactive Recognized Contributor
Usually I reboot to recovery, wipe cache (don't need to do dalvik), reboot back to ROM and everything is quick again.
I don't know why this works though.
I don't know why this works though.
Mostly correct.
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
Another method is to use the lagfix manually once a week or more frequently...
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.
Mostly correct.
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.
Thanks _that for sharing the information and time...:good:
I take the mostly correct and hate the least incorrect....:crying: Every time I talk to you. It seems like there is a language barrier. Oh yeah, it is called an Android language, hehe...
I will loose a few days researching and trying to understand what you are saying...:silly: However, I feel like that I understand android a bit more in the end and thanks for that....Now it is time for me to bang my head on the keyboard for the next few days...:crying:
Thanks for the insightful information guys, you are frickin awesome! . I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?
. I thought the lagfix app was removed from CROMI, since the trim function was no longer needed after 4.2. I might be wrong about this, but in any case I have LagFix premium which can trim partitions on a schedule, and I take it that it doesn't do any harm at least?Thanks for the insightful information guys, you are frickin awesome!
I personally like the "discard" mounting option on Cromi x.. It is just my personal preference...:laugh: I don't recall that the lagfix was a problem for me but I heard some issued stories about it but could not remember now, sorry...
Last edited:
Thanks for the insightful information guys, you are frickin awesome!
CROMI is based off ASUS' stock firmware, hence it is still Android 4.2.1 (and will likely stay that way forever since ASUS does not update the tf700 anymore). As TRIM is only available in Android 4.3 onward, Lagfix is still a relevant. As far as I know, some people reported data corruption from using Lagfix, but I personally haven't had any issue. Your mileage may vary though.
As for performance degradation, I am also quite interested in knowing why. One of the key strength of Linux over Windows is that Linux does not have this performance degradation over time and most Linux users will happily attest to this statement. Apparently, Google has somehow removed that strength when they made Android. Many people who choose iOS over Android will also cite this performance degradation as a factor since iOS does not suffer from this problem as well, if at all. At this point, I am just going to blame Dalvik VM for all this inefficiency. If you look at Windows Phone 8 (made by the same company that brought you Windows) and iOS, both run native machine code instead of a virtual machine and they don't have any drop in performance over time. Practically, a HTC HD7 with WP7 can still compete with current Android handsets in terms of UI smoothness and exhibit no stuttering nonewhatsoever, except when you started using intensive apps, but that is definitely a hardware limitation.
"Trim" is a kernel feature and is activated by using the ext4 mount option "discard", which has been in the kernel since 2010.
Expanding a bit on the issue at hand, I'm curious about two types of apps:
First one is twilight. It's much like the f.lux or redshift program for PCs making the screen red at nighttime, so that falling asleep is supposedly easier. Now I enjoy using this on any type of screen I'm in front of after dark, but the downside to this is that it makes both my tablet and phone really laggy. My phone (i9300) isn't as affected by the performance as the tf700 is, but I wonder why this sort of app slows the device down?
Second app is SwiftKey. I love this keyboard app for its functionality and its predictions. However not being a native English speaker, I also write a lot of Norwegian so I have two word lists installed. My issue is that the keyboard seems slow and sluggish in its response, and sometimes it takes forever to actually write something down. Is this related to using two dictionares instead of one? I really love this app and would like to keep on using it, as no other keyboard seems as good to me.
First one is twilight. It's much like the f.lux or redshift program for PCs making the screen red at nighttime, so that falling asleep is supposedly easier. Now I enjoy using this on any type of screen I'm in front of after dark, but the downside to this is that it makes both my tablet and phone really laggy. My phone (i9300) isn't as affected by the performance as the tf700 is, but I wonder why this sort of app slows the device down?
Second app is SwiftKey. I love this keyboard app for its functionality and its predictions. However not being a native English speaker, I also write a lot of Norwegian so I have two word lists installed. My issue is that the keyboard seems slow and sluggish in its response, and sometimes it takes forever to actually write something down. Is this related to using two dictionares instead of one? I really love this app and would like to keep on using it, as no other keyboard seems as good to me.
Adso3000
Senior Member
I also use f.lux on all our laptops. Never heard of twillight. I highly recommend and have used Lux Dash (location based sunset setting etc) for what seems like forever on Kindle Fire, Note, Note 2 and TF700 and it can even dim down to pretty much all black if you want it to. I never experienced any slow-down because of it on the Infinity.
Just last week I read about two apps that slow down the posters Infinity and one of them was Swiftkey and there was no mention of your dual language setting and I suspect it's not a dual language issue. I've used Danish & English (and briefly Spanish for Duolingo app so 3 at the same time) and also noticed it being very unresponsive, but haven't noticed any diffence with 1, 2, or 3 languages. Now it solely resides on my Note 2. Should be easy to test though, just by disabling one language and see if it makes a difference.
I can't remember what the other app was though.
It was some post or article about lowering RAM usage by, among other things, using Titanium to change certain downloadable system apps (Gmail, Dropbox etc) into user apps and then using Greenify. Hopefully Greenify will work on this new Cromi-KK ROM I just installed, but that's on tomorrow's To Do List. Note: Greenify can only do system apps (paid version) with Xposed installer and Xposed doesn't work with KitKat.Hope that was somewhat useful and not a complete waste of your time :silly:
Not sure if I need to create a new thread, or post here, but I'm at a loss. I feel like I've wasted a ton of money on this thing. I bought the TF700 over the Galaxy 10.1 thinking it had better specs and was going to be a great product from ASUS. First problem I had was "phantom touches" and had to send it in for repair. Now it's utterly useless. It SUPER slow, so slow that I'd rather throw it in the trash than deal with it. I've tried Clean Master, but it never seemed to help performance. I installed CROMBI-kk and it's still has poor performance. I've set the wallpaper to black (none), removed all widgets, and installed maybe 2 apps so far. I also tried LagFix but it says it doesn't have permission to modify the directories (or something like that). I've ensured that Root is enabled under Developer Options.
My old Incredible (v1) runs better than this. I really don't know what to do. It's very frustrating. I even wasted the money on the keyboard attachment but in combination with the lag, I can't even bear to use it. I downloaded 2048 and swipes are slow, and once the tiles move, sometimes it takes a couple of seconds for the numbers to merge.
Is there ANYTHING I can do? I've looked through the suggestions. Am I missing something? Does EVERYONE have this problem with their TF700? I wrote ASUS about it and basically said "since you unlocked the device, we would have to replace the mainboard for $300 (parts + labor) in order to undergo any out-of-warranty diagnostics." The only reason I unlocked it was because I've heard that the performance problems were due to the ASUS software, so I thought installing a custom ROM would be the answer to my problem.
Any idea if this is a hardware issue, or something that can be fixed in the software?
My old Incredible (v1) runs better than this. I really don't know what to do. It's very frustrating. I even wasted the money on the keyboard attachment but in combination with the lag, I can't even bear to use it. I downloaded 2048 and swipes are slow, and once the tiles move, sometimes it takes a couple of seconds for the numbers to merge.
Is there ANYTHING I can do? I've looked through the suggestions. Am I missing something? Does EVERYONE have this problem with their TF700? I wrote ASUS about it and basically said "since you unlocked the device, we would have to replace the mainboard for $300 (parts + labor) in order to undergo any out-of-warranty diagnostics." The only reason I unlocked it was because I've heard that the performance problems were due to the ASUS software, so I thought installing a custom ROM would be the answer to my problem.
Any idea if this is a hardware issue, or something that can be fixed in the software?
sbdags
Inactive Recognized Contributor
Something is not right mate.
Confirm what boot loader you are on please, which recovery and how you updated the ROM then we can get you setup so experience your tab like never before
Something is not right mate.
Confirm what boot loader you are on please, which recovery and how you updated the ROM then we can get you setup so experience your tab like never before
I followed the instructions in the thread, using twrp-2.6.3-that3_Signed.zip and cm-11.0-20140322-CROMBikk4.4.2-tf700t_Signed.zip. I had already unlocked it a while back with the intention of installing a ROM but never did until yesterday, But I had TWRP 2.3.3.3 installed.
I booted up the tablet, plugged it into the computer, copied over TWRP 2.6.3 (zip) and CROMBI-kk (zip) onto internal storage. Powered down and powered back in into RCK (recovery). First thing I did was an advanced wipe, wiping everything except for the SD card and internal storage. Then installed TWRP from the zip on the storage. Rebooted Recovery. Did the same advanced wipe (x2), then installed the CROMBI zip from within recovery, pretty much leaving all the defaults for the install except for I chose Google Experience Launcher (not sure why, never tried it I guess). That's pretty much it. It installed fine, didn't seem to have any errors or anything odd. Booted up fine, went through the setup process on first boot. Setup 1 Google Account, and installed a few apps (mainly just Chrome and 2048). Other apps installed by ROM were: AdAway, Google+ (for auto-backup), Maps, Hangouts, and I installed SwiftKey. Most everything else seems to be stock.
As far as bootloader, not really sure. When I do the volume-down+power boot, I see Key driver not found.. Android cardhu-user bootloader (1.00 e) released by "US_epad-10.6.1.14.8-20130514" A03. I can get into Terminal Command from TWRP so if I need to run any commands to find out any information, let me know.
Thanks for your response and willingness to help!
sbdags
Inactive Recognized Contributor
OK I don't quite understand your advanced wipe decisions. Also what is 2048?
You need to make sure you are at least wiping /data. It may be worth loading CROMBi-kk to microsd and doing a full format on internal which will do data and the whole internal sd - it'll take about 90 mins+ so nmake sure you have enough juice.
The will eliminate any remnants and left overs.
Your bootloader *should* be fine although it is slightly old as the latest one is 10.6.1.14.10 but I don't think that causes any issues. Also make sure you choose _that's kernel in the installer and it doesn't hurt to disable journaling, disable fsync and enable the 2 GPU options.
Finally after it boots go to settings, about tablet and click the build number 7 times to enable developer settings. Then go into developer settings, enable power menu, root and set your 3 animation settings to 0.5x or zero. Last but not least change the runtime from dalvik to art and then let it reboot.
Let it settle. How does it feel now?
In the past, I've read to do multiple wipes, but the items I'm wiping should be all except the SD_CARD and Internal Storage. 2048 is a little number game: http://gabrielecirulli.github.io/2048/ (https://play.google.com/store/apps/details?id=com.digiplex.game)
When I get some free time, I'll come back and give this a shot. Thanks for all your help.
I'll make a note of this as well when I go back through this. I'm not sure where I had the choice of kernel in the installer, but I'll make sure I choose _that's. I don't know what those other options are, but again, will keep an eye out for them.
Thank you for all this information. When I get some time, I'll give these steps a shot and hopefully be much happier with my tablet. Thanks again!
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
2
Mostly correct.
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
Another method is to use the lagfix manually once a week or more frequently...
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.1
That is a very good question...:good: I have the same question but I can not find a solid answer for it. I hope that some developers or experts can give us a good definition of it...
This is what I know but I may be totally off and wrong, haha..
When you first install the new ROM, all your partitions are new and clean. When you write something to your data partition, it is most of the case, it just writes data to a clean blocks without erasing the blocks. After a while, most of your blocks are dirty even though they are unused or available for writing. This is the part that users see the degradation. When a new data is writing to the available and dirty blocks, first the kernel has to erase the block before writing to it. The erase process takes a lot longer than the write process according to my research...:crying: On our tf700, writing to the internal sd or mmc is very slow already. On top of that, the erasing process has to be done before writing the new data to your internal sd. If you do the math, the performance of the writing will degrade more than twice comparing the new installation..:crying: I believe that google noticed this issue so they implemented the fsTRIM on the newer kernel source to tackle this problem..:good:
However, when you are using the fsTRIM, you have to sacrifice some slightly performance loss and you don't notice performance degradation over time.. During the normal usage, I can not tell the differences if the fsTRIM is on or off but I did see the small performance loss with a bench test.. In short, I know both _that and hund's kernel support the fsTRIM but it is disable as a default. You can try to enable it to see if it is solving your degraded problem....Good luck...:fingers-crossed:
Another method is to use the lagfix manually once a week or more frequently...11Mostly correct.
It's the controller in the eMMC that does that. The peculiarities of flash memory - no way to directly overwrite data, need to erase in large blocks before writing, can't write to the same location too often or it wears out - are all hidden by a small (and not very smart, in our case) controller. The kernel sees a block device that it can use like a mechanical hard drive.
This depends how much data is written and how much space is free. If you have 10 GB free and you run lagfix once, you won't benefit from running it again until after 10 GB have been written to flash. Random writes cost more than their real size (see above, overwrites must be simulated by rewriting larger blocks), sequential writes translate to about their actual size written to flash.
Thanks _that for sharing the information and time...:good:
I take the mostly correct and hate the least incorrect....:crying: Every time I talk to you. It seems like there is a language barrier. Oh yeah, it is called an Android language, hehe... I will loose a few days researching and trying to understand what you are saying...:silly: However, I feel like that I understand android a bit more in the end and thanks for that....
Now it is time for me to bang my head on the keyboard for the next few days...:crying:
