[Galaxy S I9000 Themes and Apps] mnazim:
Configuration:

OK... Here's what I use on a daily basis. And I cannot express the smoothness...Butter pure Butter...!

Currently I am running everything in GPU configuration...! testing... and its smooth believe me... it is...

Slim Bean Latest

Semaphore Latest

1140 MHz

Ondemand/Interactive

No-op/SIO

Bigmem

512 kB read ahead

Sensitive Touchscreen

Patched JB Hugemem Libs

ROM Slimmer

Super Launcher+ Mod

Inverted Apps + Framework

Changes:

Bytecode Verification and Optimization

The system tries to pre-verify all classes in a DEX file to reduce class load overhead, and performs a series of optimizations to improve runtime performance. Both of these are done by the dexopt command, either in the build system or by the installer. On a development device, dexopt may be run the first time a DEX file is used and whenever it or one of its dependencies is updated ("just-in-time" optimization and verification).

There are two command-line flags that control the just-in-time verification and optimization, -Xverify and -Xdexopt. The Android framework configures these based on the dalvik.vm.verify-bytecode property.

If you set:

adb shell setprop dalvik.vm.verify-bytecode true

then the framework will pass -Xverify:all -Xdexopt:verified to the VM. This enables verification, and only optimizes classes that successfully verified. This is the safest setting, and is the default.

If dalvik.vm.verify-bytecode is set to false, the framework passes -Xverify:none -Xdexopt:verified to disable verification. (We could pass in -Xdexopt:all, but that wouldn't necessarily optimize more of the code, since classes that fail verification may well be skipped by the optimizer for the same reasons.) Classes will not be verified by dexopt, and unverified code will be loaded and executed.

Enabling verification will make the dexopt command take significantly longer, because the verification process is fairly slow. Once the verified and optimized DEX files have been prepared, verification incurs no additional overhead except when loading classes that failed to pre-verify.

If your DEX files are processed with verification disabled, and you later turn the verifier on, application loading will be noticeably slower (perhaps 40% or more) as classes are verified on first use.

For best results you should force a re-dexopt of all DEX files when this property changes.​

Execution Mode

The current implementation of the Dalvik VM includes three distinct interpreter cores. These are referred to as "fast", "portable", and "debug". The "fast" interpreter is optimized for the current platform, and might consist of hand-optimized assembly routines. In constrast, the "portable" interpreter is written in C and expected to run on a broad range of platforms. The "debug" interpreter is a variant of "portable" that includes support for profiling and single-stepping.

The VM allows you to choose between "fast" and "portable" with an extended form of the -Xint argument. The value of this argument can be set through the dalvik.vm.execution-mode system property.

To select the "portable" interpreter, you would use:

adb shell setprop dalvik.vm.execution-mode int:portable

If the property is not specified, the most appropriate interpreter will be selected automatically. At some point this mechanism may allow selection of other modes, such as JIT compilation.

Not all platforms have an optimized implementation. In such cases, the "fast" interpreter is generated as a series of C stubs, and the result will be slower than the "portable" version. (When we have optimized versions for all popular architectures the naming convention will be more accurate.)
​

Priorties [credits zeppelinrox]:

BACKUP_APP_ADJ:I = 0x7

FOREGROUND_APP_ADJ:I = 0x0

HEAVY_WEIGHT_APP_ADJ:I = 0x4

HOME_APP_ADJ:I = 0x0

PREVIOUS_APP_ADJ:I = 0x5

SERVICE_ADJ:I = 0x6

SERVICE_B_ADJ:I = 0x8

VISIBLE_APP_ADJ:I = 0x3

Source: elinux
​