Database Info

Pre research compilation performance thread.

I'd like to come up with a list of performance and battery optimizations for AOSP android devices. I will base this off of cyanogen, and it's derivatives, like evodeck, which is what I use.
I have a few questions. I will edit when I get answers, to include them.
For raw performance, which is better, Yaffs, or EXT2. Also, does that question actually fluctuate depending on which partition? I just became aware that EXT4 will be the new standard partition, but that's just EXT2, with extents (which on flash is worthless overhead), and journaling, which uses a lot of write cycles.
Does 3g turbocharger affect battery usage? Does it actually work?
What is people's opinion on v6 supercharger and 3g turbocharger?
Basic optimizations that I start off with for pure battery
Setup power control widget. Disable autosync on disable wifi, have 2g/3g disable or enable based off of background data.
Use HAVS custom kernel, with undervolt as far as you can go while maintaining stable, using vipermod. Use smartass governor. Some people perfer interactiveX.
If for whatever reason, you can not use a HAVS kernel, use setCPU to set your screen off settings to go to powersaver governor, just so it doesn't have to monitor use. Underclock your lowest speed to comfort level. I like 128MHZ on my evo.
For amoled screens, use black as often as you can, while for LCD screens, use white as often as you can.
Shut off haptic feedback, and other input based sounds.
Performance and battery
Disable Animations, of nearly any kind in settings. Set transparency to 16bit.
Consider lowering VM heap size, to prevent garbage collection, experiment as necessary.
If you have sufficent memory (512+), then lock messenger and homescreen in memory.
Consider using v6 supercharger to make android properly setup for the amount of ram that you have, instead of a generic value.
Remove DSP, since it increases processing usage.
Set noatime and nodiratime, to prevent disk writes.
Use push mail instead of polling to save battery.
Use a static wallpaper, or no wallpaper.

[Discussion] Ways to improve UI response on Android

Given the recent hoopla in the blogosphere about how iOS places higher priority on User Interface actions than Android. I was wondering what ideas can be implemented in current Android or Linux kernels to get better UI response.
Overclocking or upgrading to a faster phone is the brute force way, a smarter way would be to give higher priority to user input instead of benchmark/multitasking score numbers. I think it makes sense to give the User input highest priority because in computation timeframes, user input is rare, and considering how important smoothness affects overall perception & enjoyment of a device, it's a good idea to allow other OS background tasks to take a backseat when the User wants to do something.
I'll start the discussion with two ideas I've implemented in a kernel recently that has shown improvements in UI response.
1. Switched to using SIO (Simple IO) scheduler (similar, but slightly lower benchmarks than Noop). Main difference is SIO prevents the system from hogging resources when large amounts of data needs to be read/written. It has a timeout so UI threads has a chance to run also.
2. Switched the touchscreen driver interrupt service request from using the general events workqueue (schedule_work()) to a dedicated workqueue (queue_work()). Touchscreen generated actions get to ride in the fast lane.
Any other ideas people have?

How bout some NSA IN THAT KERNEL
via Dan swagger

Usefull links, that clear things out:
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC
http://blog.crazybob.org/2011/12/truth-about-android-ios-ui-performance.html

the thing is i may be using a note but when using ICS with apps that are updated for ICS, i feel its smooth enough. the real difference is i think ios uses completely different method for scrolling i.e. the bounce function and slight delay in finger recognition. same with ios touch recognition, it just somehow is better no doubt.
btw when i was miui with bounce it definitely felt smoother but although it wasnt ios smooth.
Sent from my Galaxy Note using XDA App

The main difference between ios and android is the fact they use ram in two totally different ways. Ios handles ram in a manner to make the user interface smooth as possible all the time while android frees ram to make multitasking better. The problem that android has is changing the way android handles ram to make the interface smoother for the user. They wont be able to for a long time because they have to do a total overhaul on the whole dalvik cache type setup that android uses.
Sent from my Incredible 2 using Tapatalk

i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?

I liked the supercharger when I used the Droid Eris but since I've upgraded I get more redraws than without it. I used the 768hp I think.
Sent from my Incredible 2 using Tapatalk

you could edit the ramdisk to set more of a priority to rosie.apk or whatever launcher you use...just a thought

That would be the same as locking home in memory.
Sent from my Incredible 2 using Tapatalk

shad0wboss said:
i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?
Click to expand...
Click to collapse
There are a number of issues that contribute to a "sluggish experience". The supercharger v6 script mainly keeps more memory free so that switching to new apps cuts down on the garbage cleanup of older apps. One of the downsides I've noticed with more aggressive lowmemkiller settings is a lot of apps get killed in the background when they need to stay for when users want to multitask.
The hardware acceleration route has downsides too from what I've heard, it requires more RAM per app just to have it enabled.
One of the articles posted earlier has good insight. Mainly because a lot of apps share a general events queue, and developers should not have a lot of blocking code in there, but developers make mistakes. The tools available for Android to develop and tweak UI performance seems lacking at this point.

How about SIGSTOPping everything else when you touch?

Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to General

does it work with samsung i9000?

Supercharger?
Sent from my Sabotaged Droid Incredible 2.

I find that either turning off cpufreq (by using the Performance governor) or increasing the lower frequency makes things a bit more snappy. For most governors, there's a delay between CPU load and the frequency being increased. This delay is usually noticeable if the CPU load is due to me working with the interface. By increasing the min frequency to, say 800mhz on a Nexus S, this makes things a lot more snappy than the default setting of 200mhz.
Another thing that helps with the smoothness (at least for me, in ICS) is the setting that forces GPU acceleration for all apps. For example, apps these days (well twitter and Facebook) have that pull down to refresh widget from iOS. Without forcing GPU acceleration, the rotating arrow animation usually hitches quite a bit, but is smoothed out with this setting on. This setting can be found in the developer options in the settings.
Hope these help,
- chris

Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.

System tuner pro has alot of tweaking options that on memory use
those that use launcher pro can find a memory usage setting in launcher pro to.

disconnecktie said:
Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.
Click to expand...
Click to collapse
Agreed, but the whole point here was to help improve UI responsiveness. Without rearchitecting the OS, a good way is to allow the CPU (which is busy sharing its resources with non-UI work) to react more quickly is to ensure the CPU is at a higher clock rate before the UI needs it.
As for battery life, it really depends on your usage pattern. If you have a lot of background processing going on, preventing the CPU from going to sleep when idle, you may be better off scaling back the minimum cpufreq frequently. If your CPU actually goes to sleep, give scaling things up a try. A handy tool you can use to see how often the CPU is sleeping is CPU Spy. To see which apps are keeping the CPU awake, there's a program called Better Battery Stats available on XDA and market.
As for stability, I don't mean over clocking the CPU...all I'm suggesting is to increase the frequency the CPU goes to when the screen is on, but nothing much is happening. This should still keep things within safe limits.
Hope this helps,
- chris

I find the interactive governor does a very good job of ramping to max right from idle (instead of waiting even a few ms like ondemand does). It assumes coming out of idle the CPU is starved. Then scales back once demand lowers. No fancy locking to min freq when screen is off (which can stutter some background apps).

There is many thing what can be done in the code of the applications. For example once I had a really sluggish app. It turned out that while I was dragging an item in the UI, the UI needed to be relayouted, and the draw calls were simply postponed: in android (at least that was the case before ICS) the drawing of the UI is delayed while the UI thread is too busy with events and layout requests.
To find these issues it's really useful to use traceview.

[Q] Optimal cm9 performance settings?

Hello everyone,
I've been using the cm9 release candidate since it was released, and still can't figure out how to make it snappy (I was on Apex before, and found it much more responsive). I'm not sure which the performance/memory management settings the Nexus S can handle well (there are lots of other threads for other phones, but I'm not sure if some of the settings require better hardware), so I'd appreciate it if anybody could tell me what they've found to be good for the following options:
Performance settings:
- Surface dithering
- 16bit transparency
Memory management:
- Allow purging of assets
- Kernel samepage merging
Misc. information that may or may not be relevant:
- Using Matr1x kernel (CFS, v21.0 I think)
- Processor is running at 200/1200 most of the time, ondemand governor (same settings that used to give me great performance on Apex).
- Also tried running Supercharger script, but it didn't seem to change things as much as it usually does
- Fixing permissions didn't fix it
- Battery life seems fine
- What I mean by "unresponsive" is that the launcher takes longer than usual to redraw and is laggy switching between windows, apps often force close or take forever to start up, and the browser reacts much more slowly to pinches, swipes, etc.
Thanks!
tl;dr: CM9 users, please share your performance + memory management settings. Explanations not required, though appreciated.

niiiiick said:
Hello everyone,
I've been using the cm9 release candidate since it was released, and still can't figure out how to make it snappy (I was on Apex before, and found it much more responsive). I'm not sure which the performance/memory management settings the Nexus S can handle well (there are lots of other threads for other phones, but I'm not sure if some of the settings require better hardware), so I'd appreciate it if anybody could tell me what they've found to be good for the following options:
Performance settings:
- Surface dithering
- 16bit transparency
Memory management:
- Allow purging of assets
- Kernel samepage merging
Misc. information that may or may not be relevant:
- Using Matr1x kernel (CFS, v21.0 I think)
- Processor is running at 200/1200 most of the time, ondemand governor (same settings that used to give me great performance on Apex).
- Also tried running Supercharger script, but it didn't seem to change things as much as it usually does
- Fixing permissions didn't fix it
- Battery life seems fine
- What I mean by "unresponsive" is that the launcher takes longer than usual to redraw and is laggy switching between windows, apps often force close or take forever to start up, and the browser reacts much more slowly to pinches, swipes, etc.
Thanks!
tl;dr: CM9 users, please share your performance + memory management settings. Explanations not required, though appreciated.
Click to expand...
Click to collapse
You don't need to mess with those settings.
Besides, if your applications FC, it's likely because of:
a) instability regarding your overclock
b) instability regarding the undervolt that matr1x kernel comes with
c) the fact v21 was canned due to being judged unstable by so many, upgrade to v22
d) all of these
Cheers

If you don't know what a setting does, don't change it. Messing with the CM performance settings if you don't know what you're doing is a great way to mess your phone up.

063_XOBX said:
If you don't know what a setting does, don't change it. Messing with the CM performance settings if you don't know what you're doing is a great way to mess your phone up.
Click to expand...
Click to collapse
are you completly retarded? there doesnt happen much when you change the settings there. you are talking like the settings are just for pros and he is a kid, lol. kernel samepage merging for example just "bonding" two similiar proccesses so they dont need too much ram.

Fensterbank said:
are you completly retarded? there doesnt happen much when you change the settings there. you are talking like the settings are just for pros and he is a kid, lol. kernel samepage merging for example just "bonding" two similiar proccesses so they dont need too much ram.
Click to expand...
Click to collapse
Are you? This thread has been dead for almost 3 months. The OP had his answer. Resurrecting this thread just to argue is incredibly pointless.

Some tweaks - could we use these?

hey, just stumbled upon this:
Adrenaline™ Engine
http://forum.xda-developers.com/showthread.php?t=1604315
apparently it improves ram by using zipalign, improves sd card read/write and mounting, as well as network tweaks, and more!
I'm wondering if we could apply it to the ChaCha.
The tweaks seem pretty generic. I imagine only minor details would need to be tweaked to apply to other devices.
I've already seen parts of it applied to other devices.
If some dev wouldn't mind taking a look at it and giving an opinion, I'd appreciate it

kronflux, have u used it?

[Q]Android Build.prop question

Today Im going to optimize and
investigate the high cpu consumtion in systemui and bad 3D performance of apps
I have some question about the
build.prop in omni and carbon 4.4
I have read some thread which talk about the android composition type
so I am going to adding these two line
debug.composition.type=
persist.sys.composition .type=
Click to expand...
Click to collapse
1.What does these two lines means and doing for?
2.Which Android component will affected by these line,If I modified it
3.which lines will affect the whole system others will only affect the user /system apps itself?
Second section
It provide many switches for us
cpu,gpu,mdp,dyn,c2d
1.what does this switches means for the above two build.prop line
which one is include and suitable to use for our Tegra 2 AP20H(Harmony)

persist.sys.composition.type will set the composition type.
1.What does these two lines means and doing for?
debug.composition.type
=gpu will disable hardware overlays and use GPU for screen compositing
=cpu will use hardware overlays
=dyn will use cpu and gpu dynamically.
=c2d is like dyn but it prefers gpu more.
both should be kept same. try setting gpu. I think it will result into more battery life.
2.Which Android component will affected by these line,If I modified it ?
Screen composition will be affected. You might notice difference in scrolling and video playing.
3.which lines will affect the whole system others will only affect the user /system apps itself?
I don't get it.
which one is include and suitable to use for our Tegra 2 AP20H(Harmony)?
Try gpu and see what happens.
Report back after testing.

future questionvery what is mdp ?
this is default compoststion type in kiktat
does mdp supportour tega 2 harmony?
For third question
I mean which line will affect whole system composition,and which line will affect only composition for apps
What is screen composition does it have any an relationship with egl?