Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[Q] What makes the tablet slow?

OP vonVaffel

7th March 2014, 05:05 PM   |  #1  
OP Junior Member
Flag Oslo
Thanks Meter: 0
 
20 posts
Join Date:Joined: Feb 2013
More
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?
7th March 2014, 06:44 PM   |  #2  
Senior Member
Thanks Meter: 607
 
1,508 posts
Join Date:Joined: Jun 2013
Quote:
Originally Posted by vonVaffel

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... 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... 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.. I believe that google noticed this issue so they implemented the fsTRIM on the newer kernel source to tackle this problem..

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...

Another method is to use the lagfix manually once a week or more frequently...
The Following User Says Thank You to LetMeKnow For This Useful Post: [ View ]
7th March 2014, 07:27 PM   |  #3  
sbdags's Avatar
Recognized Contributor
Flag Kenilworth, Coventry
Thanks Meter: 13,243
 
11,667 posts
Join Date:Joined: Jun 2007
Donate to Me
More
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.
The Following 2 Users Say Thank You to sbdags For This Useful Post: [ View ]
7th March 2014, 07:43 PM   |  #4  
Senior Member
Thanks Meter: 607
 
1,508 posts
Join Date:Joined: Jun 2013
Quote:
Originally Posted by sbdags

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.

Thanks sbdags for the information...
The Following User Says Thank You to LetMeKnow For This Useful Post: [ View ]
7th March 2014, 08:40 PM   |  #5  
Recognized Contributor
Thanks Meter: 2,513
 
3,545 posts
Join Date:Joined: Oct 2012
Quote:
Originally Posted by LetMeKnow

This is what I know but I may be totally off and wrong, haha..

Mostly correct.

Quote:
Originally Posted by LetMeKnow

When a new data is writing to the available and dirty blocks, first the kernel has to erase the block before writing to it.

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.

Quote:
Originally Posted by LetMeKnow

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.
The Following 2 Users Say Thank You to _that For This Useful Post: [ View ]
7th March 2014, 11:40 PM   |  #6  
Senior Member
Thanks Meter: 607
 
1,508 posts
Join Date:Joined: Jun 2013
Quote:
Originally Posted by _that

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...

I take the mostly correct and hate the least incorrect.... 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... 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...
The Following User Says Thank You to LetMeKnow For This Useful Post: [ View ]
8th March 2014, 01:50 PM   |  #7  
OP Junior Member
Flag Oslo
Thanks Meter: 0
 
20 posts
Join Date:Joined: Feb 2013
More
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?
8th March 2014, 07:51 PM   |  #8  
Senior Member
Thanks Meter: 607
 
1,508 posts
Join Date:Joined: Jun 2013
Quote:
Originally Posted by vonVaffel

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 personally like the "discard" mounting option on Cromi x.. It is just my personal preference... 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 by LetMeKnow; 8th March 2014 at 07:54 PM.
9th March 2014, 07:04 AM   |  #9  
Senior Member
Flag Singapore
Thanks Meter: 55
 
344 posts
Join Date:Joined: Mar 2012
More
Quote:
Originally Posted by vonVaffel

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?

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.
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes