[Hero CDMA Android Development] jasonmaloney:
I see you've stated you would like to focus on quality. So let's skip all the drivel and maybe you could answer some questions about how the things you've posted are supposed to be increasing performance.

Let's start with the libGLES_qcom.so file. This matches the checksum of the original file of the same name from the Droid Eris. Similar hardware to ours, but different in important ways.

Take a look at the information this file exports. It doesn't support GL_OES_EGL_image, which the built-in Android PixelFlinger supports natively. This will cause problems. If you don't believe me, try running Neocore from the market and see if it displays anything more than a bunch of glowing dots. None of the textures show up.

The libGLES_qcom.so that ships with the Hero is actually a bit-for-bit copy of the libGLES_android.so file. I've actually seen better graphical performance (especially in Angry Birds) on CM7 by switching to libGLES_android.

---------------------------------

The "misc" props:

dalvik.vm.startheapsize=32m

This is a bad idea. This means that every single program running in the VM will start with a heap size of 32m, rather than expanding to it. You'll be running out of memory.

windowsmgr.max_events_per_sec=60

Read the source code. This is already the default value.

debug.sf.hw=1

Read the source code. This does absolutely nothing, unless "debug.sf.hw=0" had been set for some reason (Hint: I've never seen a HeroC ROM with this set).

ro.opengles.version=131072

This is going to cause problems. This value is a 16.16 number. What this means is that it holds both a 16-bit integer value and a 16-bit decimal value. In binary, 131072 is 0000 0000 0000 0010 0000 0000 0000 0000, meaning 2 | 0, or OpenGL ES 2.0. Some people have said that faking support for 2.0 will enable additional features in some programs (such as Google Maps), but this may cause undefined behavior in other programs.

ro.telephony.call_ring.delay=1000

No complaints about this one, except that most ROMs already define it.

ro.mot.eri.losalert.delay

Do you know what this actually does? It's a motorola-specific ("mot" in the prop name) value that does nothing on the HeroC.

---------------------------------

The "net" props:

ro.ril.hsxpa=2

ro.ril.gprsclass=8

ro.ril.hep=1

ro.ril.enable.dtm=1

ro.ril.hsdpa.category=24

ro.ril.enable.a53=1

ro.ril.enable.3g.prefix=1

ro.ril.htcmaskw1.bitmask=4294967295

ro.ril.htcmaskw1=14449

ro.ril.hsupa.category=3

Most of these don't do anything on CDMA phones. Do you have any idea what the bitmask value actually changes? I haven't done any reverse engineering of the HTC RIL library to find out, but if you have, I would love to see what you've found.

wifi.supplicant_scan_interval=200

This is hardly a "performance" value. This is much, much longer of an interval than the default value on most ROMs.

net.dns1 0.0.0.0

net.dns2 0.0.0.0

How does defining no DNS server make things faster?

---------------------------------

The "vm" props:

The following lines you've included change absolutely nothing on the stock CM7 kernel:

/proc/sys/vm/swappiness (same as default value)

/proc/sys/vm/vfs_cache_pressure (same as default value)

/proc/sys/vm/drop_caches (same as default value)

/sys/block/mmcblk1/queue/nr_requests (doesn't exist)

/proc/sys/fs/inode-max (doesn't exist)

/proc/sys/kernel/shmmni (doesn't exist)

/proc/sys/kernel/ngroup_max (doesn't exist)

/proc/sys/kernel/shmax (doesn't exist)

/proc/sys/kernel/shmall (doesn't exist)

/proc/sys/vm/oom_allocating_task (doesn't exist)

/proc/sys/kernel/hung_task_timeout (doesn't exist)

/proc/sys/kernel/sched_compat_yeild (doesn't exist -- you spelled yield wrong)

/proc/sys/kernel/sem (doesn't exist)

/proc/sys/kernel/msgmni (doesn't exist)

/proc/sys/kernel/msgmax (doesn't exist)

It's very obvious you just copied-and-pasted these from somewhere, seeing as most of them don't even exist in our kernel. The fact that some of them are indented by spaces and others by tabs doesn't bode well either.

echo "70000" > /proc/sys/fs/overflowgid

echo "70000" > /proc/sys/fs/overflowuid

Bad idea. The entire reason these exist are to change GIDs and UIDs that "overflow" beyond a 16-bit value, and you've set the overflow value to something that's larger than a 16-bit value.

echo "32" > /data/property/persist.sys.vm.heapsize

Bad idea if JIT is enabled.

echo "70000" > /proc/sys/fs/file-max

Did you notice you set this twice? Probably not, since it's set in two different groups of copied lines.

echo "nameserver 0.0.0.0" > /etc/resolv.conf

echo "nameserver 0.0.0.0" > /etc/resolv.conf

Both of these lines do the same thing -- wipe out the /etc/resolv.conf file and replace its contents with the quoted information. Once again, I don't see how defining no default nameserver is going to make the internet faster, but if you explain why, that would be great.

---------------------------------

The only things I can see here that will really increase performace is the setting of the low memory killer settings, and enabling the performance governor. But the performance governor is a bad idea here because you're setting the maximum CPU frequency to 691. The performance governor ignores the minimum CPU speed and keeps the processor locked into the maximum speed, which in this case is an overclocked value. I'd be willing to bet that this is what's causing people's reboots during charging -- the phone/battery are probably overheating.