Database Develop

ROM Comparison Analysis

Many of you guys are good at programming and can whip up cabs in your sleep--I'm not so good at C++, etc but here's my contribution, hope it helps someone.
Analysis of Wizard ROMs
Objective: Try to determine if there is performance improvements in newer ROMs. Also to see if the 12->8 MB paging size has a measureable effect in performance.
Summary of Results:
There doesn't appear to be much of a measurable difference in performance among these ROMs, with the exception of the last two ROMs tested. For the rest of the pack, the hardware responds about the same with a little noise. Summitter's 2.17 ROM appears a little above average, but this could be just a testing glitch, and its not significantly above the others. This appears to indicate that the upgrade to decrease the paging pool has no effect (to this benchmark).
I'm concerned about the consistency of results with the last two. They were performed under slightly different test conditions (at home, vs at work for the others), and there's no reason ShogunMark's at least (if not both) shouldn't be closer to the others in performance. I plan to rerun these tomorrow and see how they compare.
Method: I flashed a decent cross-section of the ROMs out there--don't feel insulted if yours isn't included. In fact, I'd be happy to add yours to the mix--just ask! For each ROM listed, I flashed then immediately recorded stats from Settings>System> About, Device Info, and Memory. Then added PC Pro Labs Pocket PC Benchmark and embedded vb runtime (required for Benchmark), removed USB cable, soft-reset and ran benchmark software once to obtain last few columns of results.
Assumptions: The biggest assumption is that this is decent benchmarking software. While it was written for WM2003, its probably not a big stretch to assess WM2005. I konw Spb has a benchmark program, but it ran for about 1.5 hours on the first ROM. Too long for me, guess I'm just impatient! Other big assumption is that higher values are better, although this appears inversely releated for the file read/write benchmarks compared to the kb/sec measurements. This may also be true for the others, butsince they're all about the same it really doesn't matter.
Additional Observations: At the very least, this was an interesting exercise to record some comparable data regarding the different ROMs. ROMs have evolved over time, and sometimes there are questions about which ROM contains what, etc. This might lead to another idea where we keep track of the ROMs in some type of registry to track consistent information about each.
Analysis Improvements: This could be improved by using more current benchmark software. Spb Benchmark is a decent candidate, but takes a while to run. Also, the analysis could be improved with many benchmark runs per ROM instead of just one run. This would average out the "noise" betweens runs and might give a better indication of slight performance trends.
Finally, the method used above will be repeated under similar conditions for the last two ROMs to see if the provided results are valid.
Terms:
BM - Benchmark
GDI - graphics display test
CPU - central processing unit
kb/s - kilobytes per second (used for read/write tests).

wow, its like a report card for roms, lol and good work by the way...
however, is it possible to lay out the results in a better format?

nevermind.. i noticed this new damn board wont let you upload an excel file, i did it myself.. thanks again.. and i agree it is odd that the last 2 are lower than everyone else's but still close to each other.. i would vote computer as well

Good job! This pretty much confirms what I've been thinking for a long time...there's no real difference in performance. If you're going to add or alter the list, I'd like to also see the stock T-Mobile 2.26 rom thrown in there as well. Maybe if people see that "it seems faster" doesn't mean anything and they're all pretty much the same, they might think twice about risking their expensive toy for a reason they probably can't define.

zip it up and then upload it...

lvlolvlo said:
zip it up and then upload it...
Click to expand...
Click to collapse
Good idea! Zip includes the Excel file of results and run report for each of 8 runs performed so far with PC Pro benchmark.
Didn't get to updating this with my work computer today, but I will in the next few days.

Measuring units?
hi, jorge_culv, least numbers mean quicker?

Good question, and I honestly don't know the answer. There's no documentation with this benchmark, even on the hosting company's website. Other benchmarks I've used had higher numbers as better. There is one clue if you look closely at the file read and write tests for each ROM. It appears the lower benchmark scores match up with the faster read and write speeds, so for those it appears lower is better, not sure if that also applies to the CPU and graphics tests.
Also, I'm real hesitent about the last 2 runs--don't read too much into those until I can do more follow up testing (hopefully in the next few days).

markgamber said:
Good job! This pretty much confirms what I've been thinking for a long time...there's no real difference in performance. If you're going to add or alter the list, I'd like to also see the stock T-Mobile 2.26 rom thrown in there as well. Maybe if people see that "it seems faster" doesn't mean anything and they're all pretty much the same, they might think twice about risking their expensive toy for a reason they probably can't define.
Click to expand...
Click to collapse
Mark, I'll try to throw in a T-Mo ROM as well. I'm not sure if this test really proves there's no difference in performance. I might be splitting hairs, but maybe it only proves there's no difference in CPU math, graphics or file read/write--in other words, the ROM upgrades affect performance in ways not measured by this benchmark. The factors measured by this benchmark sure seem more hardware related and maybe not influenced by the ROM at all. I was really hoping for a difference between the newer "30MB" roms, as that may affect read/write speed through the smaller page file, but the verdict is still out...

True, but it might be interesting to take a look at. I don't mean to come down on people creating these roms but personally, if there's a performance difference between any of them and stock 2.26, it's so small that I've never noticed it. When you compare a minute performance difference to the boost of overclocking the cpu, you wonder why you ever bothered risking the phone in the first place. At least I wondered why and, unable to come up with an answer other than "because I can" and not really wanting to throw away $350, I stopped putting new roms on the phone and won't do it again without a damn good reason.

Vladimyr said:
hi, jorge_culv, least numbers mean quicker?
Click to expand...
Click to collapse
Lower the number the better except for File read/write. I'm intrigued as to what gives the bottom two their boost in the benchmarks.

so what do you guys suggest as the best rom with both speed / batteries / stability?

More testing
I have 3 ROM version by this moment:
Qtek 2.18
T-mobile 2.26
AKU 3.2 on T-mobile 2.26
And i make test of CPU load on every ROM update by Rhino Stat.
On Qtek 2.18 and AKU 3.2 on T-mobile 2.26 CPU has constantly load 8-9% in stand-by mode.
And T-mobile 2.26 ROM has 0-1% CPU load in stand-by mode.

Is there a JIT enabled rom for the Vogue?

I just read about a G1 getting a LinPack score of about 3.5ish. Most of the nearly 100% improvementwas attributed to using a rom with JIT. Since the G1 is very similar to the Vogue shouldn't we be able to get similar results.
I am currently getting 1.65.
D
-------------------------------------
Sent via the XDA Tapatalk App

If you thinks that's impressive, you should check out the new Froyo 2.2.
The Nexus One, which has 2.1 got a scrore of 6.5-7 MFLOPS, but with 2.2 it got 37.5 MFLOPS! That's an incredible performance increase.
I want 2.2, the G1 owners can keep their JIT compiler. Them fancy pants people. BTW, the article says that the HTC Hero averages a measly score of about 2 MFLOPS, so us getting 1.65 isn't bad. Though why the Nexus One gets 37.5 MFLOPS with 2.2 makes me wonder. It could be that 2.2 uses the FPU that's in the SnapDragonl, instead of the interger. If that's the case then our devices can only ever do ~1.65, cause they don't come with a FPU processor.
Though if JIT does give G1 owners a boost, then it'll certainly give us a boost. G1 doesn't have a FPU either. I'm also concerned about the 3D accelerator, as we get bad performance in some tests.

The G1 and Vogue share the same chipset--although their CPU is clocked at 528 Mhz, and ours at 400 (at least natively, that is.)
That probably accounts for the difference of 1.65 vs. 2 MFLOPs result.
If the Linpack test is to scale across all platforms, and we estimate an average 400% improvement in floating point performance, we can probably expect 6-8 in terms of a MFLOPs score on Linpack with Froyo.
Real-world applications (integer arithmetic) will not benefit nearly as well as FP arithmetic, because FP arithmetic is incredibly burdensome. However, perhaps an expected improvement of.. 100%, or 2x, is reasonable (depending). Programs with small rapid loops, etc. will see the most benefit. It'll be interesting to see how the Vogue performs.
In regards to graphics / the Vogue GPU:
I'm not completely up to speed on it, but I believe a primitive driver does work for OGL 1.0-based acceleration (Neocore?) but that's it; nothing more than 1.0 (which would explain why Live Wallpapers do not accelerate properly/crash, etc.)
I was under the impression the chipset between the Vogue and the G1/Hero/Eris was the same, and that if we simply used the driver from the G1/Hero/Eris's 2.1 ROM, we'd have full 3D acceleration.. but I don't think that's the case. There's plenty of smarter individuals here who would've ascertained the same thing, but nothing available.
I think (from a GPU perspective) we have official OGL 1.0 support and that's it.

The Kaiser, like the Vogue, uses the 400 Mhz Qualcomm chip. The difference between the chip in the Vogue/Polaris/Kaiser and devices like the G1 is Mhz and small changes done to the ATI accelerator. Though, I don't think the changes for the accelerator are major.
I have no idea about our Android setup. Is it using open source drivers? Is it using a driver taken directly from another Android device and modified, like from the G1?
I also wondered about the battery life using Android with 3D acceleration. Since Android is linux and linux open source graphic drivers are horrible and usually don't have any power management, could it be our poor battery life is due to the graphics driver?
Could it also be that the graphics driver from the G1 would work on our devices, but is a proprietary driver, and therefore can't be distributed? So instead we use open source drivers to avoid legal action?
If anyone knows the answers to these questions that would be great. I'm trying to wonder why my Kaiser with Android uses more battery life when not in use. Browsing the web or talking on the phone the battery life seems normal, but it's when it's idle that it consumes power twice as fast as Windows Mobile. To me it seems something isn't totally off when the device is in standby, and I'm thinking it's graphics related.

I've tested JIT enabled dalvikvm's on both Donut and Eclair. I never saw any noticable improvement in speed. I did however observe longer boot times and odd behavior from heavy memory intensive applications. For example, the browser sometimes doesn't launch when you have clicked it.
Give the JIT dalvikvm a try. Let me know if you experience anything positive on our vogues.

Here's a post for the G1 that uses JIT.
licknuts said:
The libdvm.so that t3steve cross compiled for the DROID at the time was for Android 2.0, the library works for with newer ROMs Android 1.6 that have some eclair pieces built into the kernel, CyanogenMOD has been using bits and pieces for a while now, if other ROM builders have been using his kernel and framework than a good chance it will work for your phone as well.
Click to expand...
Click to collapse
So, does that mean we just need eclair based roms, or is there more to that?

Dukenukemx said:
Here's a post for the G1 that uses JIT.
So, does that mean we just need eclair based roms, or is there more to that?
Click to expand...
Click to collapse
Eh, I'd just wait for Froyo, for an official JIT system designed specifically for use with the native apps in Froyo as well. Running an unofficial JIT compiler with older apps may cause some problems/force closes.. who knows.

Dukenukemx said:
I want 2.2, the G1 owners can keep their JIT compiler. Them fancy pants people. BTW, the article says that the HTC Hero averages a measly score of about 2 MFLOPS, so us getting 1.65 isn't bad. Though why the Nexus One gets 37.5 MFLOPS with 2.2 makes me wonder. It could be that 2.2 uses the FPU that's in the SnapDragonl, instead of the interger. If that's the case then our devices can only ever do ~1.65, cause they don't come with a FPU processor.
Click to expand...
Click to collapse
Without JIT (multiple test runs):
~ 1.65 MFLOPS for first 15 mins or so after startup
~ 2.33 MFLOPS after 15 mins after startup
Time to enable JIT and possible problems with apps, etc. it may cause probably isn't worth it to me.

You guys should check out this thread made by garringm from the Kaiser forum, if you wanna enable JIT. It should work, considering Kaiser users are using Vogue Android builds.
You'll need the Android SDK installed on your PC. Works with Incubus26Jc's Super Eclair and mssmison's CM 5.0.7 test 3. I ran linpack and got 3.3 MFLOPS.

I find at least for our vogues, linpack is not the best thing to judge by. It more calculations based which in most cases doesn't judge load times and the agility of our applications.
As I mentioned, I've used jit on a number of Donut and Eclair roms and although linpack may report a higher score the user experience in the speed dept wasn't improved.
Infact I found app load times to be longer with a jit enabled dalvikvm.
Are you sure the linkpack score isn't acting as a placebo?

Part of the issue is using (an unofficial) JIT compiler on a system not truly designed for it.
Froyo's compiler (along with Froyo's system) are designed to work with and efficiently use the new compiler, which means the best performance (and user experience) is going to come with Froyo, not Eclair/Donut/Cupcake with an unofficial JIT compiler.
I think we should just be patient--Froyo will be out soon, and we will surely port it to the Vogue, which will answer all of our questions.

myn said:
I find at least for our vogues, linpack is not the best thing to judge by. It more calculations based which in most cases doesn't judge load times and the agility of our applications.
As I mentioned, I've used jit on a number of Donut and Eclair roms and although linpack may report a higher score the user experience in the speed dept wasn't improved.
Infact I found app load times to be longer with a jit enabled dalvikvm.
Click to expand...
Click to collapse
Yes, the load times of applications are longer. Especially when applications are already loading slowly, this certainly doesn't help.
Are you sure the linkpack score isn't acting as a placebo?
Click to expand...
Click to collapse
Linpack is probably correct, as are the delays. I've played with emulators in the past, and I understand a bit about JIT. JIT is related to dynamic compilation, which a lot of emulators used in the past. Modern emulators like Dolphin uses JIT.
The idea is that instead of compiling data interpretively, it does it all in one shot, before the program executes. That way the program runs like it was made natively for the hardware. It would make sense that the applications have a delay in execution with JIT.
G1 owners don't have a problem with this since applications launch instantly on their phones. Running JIT for them makes no tangible difference. For us it's worse because we already have a 2-10 second delay to execute applications. This just makes it worse.
Another thing to consider is that many applications don't use MFLOPS, which is the FPU we don't have. Only 3D applications use that, and we don't use many of those. At least not yet. I'd like to try Quake 3 with it and see how it runs.

Quadrant sucks, howto properly bench our devices?

I'm creating this thread based on what i read here: http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws
I'd really like to know what lagfix gives me the best results and i lost my faith in quadrant. Are there any decent alternatives? Most benchmarks i know are only good for testing cpu performance...

Its not fair to say that quadrant sucks, and particularly I don't like that the article seems to be implying that the lagfixes that a lot of us are running are simply artificially inflating the SGS's score. The SGS has the best harware on the market crippled by bad firmware, and tbh I think its the lag fix that has allowed the hardware to be reflected in quadrant scores.
Anyway, quadrant doesn't suck. Its not perfect, but it does help you determine for example, how different ROMs on the same device compare for performance, as well as showing off things like GPUs that often don't get seen.
However it just runs a series of tests and weights the results accordingly. Particularly, the I/O seems to be given a lot of weight and so can be nobbled to increase the score. However, as anyone who has experienced excessive lag on their SGS can attest, it also works the other way. Without the lag fix, the SGS is a very pedestrian device, as the ~1000 quadrant scores tell you, while with the fix it FLIES.

Actually, some people are saying they notice no difference with the lag fixes it seems. And I've also seen forums full of people saying they can hear the difference between WASAPI/Exclusive audio and shared audio in Windows. Amazingly, out of the dozens of people trying to destroy me and demand it was implemented, none of them were willing to blind test (they were all just willing to say "it's obvious"). How many people here running the lagfix, have run any kind of blind test, or test with predictable steps to demonstrate a difference? Please, raise your hand people, because there is a huge difference between "it seems lag is gone" and "Lag is verified gone".
Quadrant is a guide, it doesn't test interactivity, and it only tests a few operations. It's similar to how a browser can pass ACID3, but have terrible compliance to new standards. Because people became so convinced of benchmarks accuracy, Nvidia and ATI started optimising for benchmarks.
Normal SSD's are also blazingly fast on benchmarks initially, but if they don't have TRIM, their performance drops significantly. That's another example of something benchmarks don't accurately test (because the testing is incomplete).
Use it to get a general idea of how the phone performs (although, specs might be more useful in some cases), but you probably need profiling and a predictable list of steps to diagnose the lag exactly. Run benchmarks which test according to the types of applications you are planning to run (if you play 3D games for instance, use a 3D game benchmark). But don't rely on them exclusively to tell you how well a device performs, because only running the applications and testing them yourselves can tell you.

LostAlone said:
Its not fair to say that quadrant sucks, and particularly I don't like that the article seems to be implying that the lagfixes that a lot of us are running are simply artificially inflating the SGS's score. The SGS has the best harware on the market crippled by bad firmware, and tbh I think its the lag fix that has allowed the hardware to be reflected in quadrant scores.
Anyway, quadrant doesn't suck. Its not perfect, but it does help you determine for example, how different ROMs on the same device compare for performance, as well as showing off things like GPUs that often don't get seen.
However it just runs a series of tests and weights the results accordingly. Particularly, the I/O seems to be given a lot of weight and so can be nobbled to increase the score. However, as anyone who has experienced excessive lag on their SGS can attest, it also works the other way. Without the lag fix, the SGS is a very pedestrian device, as the ~1000 quadrant scores tell you, while with the fix it FLIES.
Click to expand...
Click to collapse
But do you really think that one-click-lagix or whatever is that much faster than mimocan's one (like 2800 vs 1800)? I don't think so...

andrewluecke said:
How many people here running the lagfix, have run any kind of blind test, or test with predictable steps to demonstrate a difference? Please, raise your hand people, because there is a huge difference between "it seems lag is gone" and "Lag is verified gone".
Click to expand...
Click to collapse
*raisehand*
Predictable steps to demonstrate a difference:
1. Use 2 SGS, firmware of your choice
2. One with, say, 1 Click Lag Fix - the other one stock
3. Now for the test, perform simultaneously:
3.1. Open Market and go to "Downloads", update an app, close.
3.2. Open Contacts, quickly switch to favourites, dial Number. Drop call. Exit.
3.3. Open Messaging, conversation of your choice, quickly switch the writing language, write, send, exit.
3.4. bla bla goanforeva
Now if you don't notice an improvement there and in many other cases you most certainly have done something wrong.
If you are saying people are just being placebo-ed you are implying that everybody else besides you is unable to tell a real difference. Think about it, maybe it's the other way around.

When I got my device it came with the Asian JG4 firmware I think and I used it for 48hrs as a point of reference for this so called "lag" I updated my firmware to the latest we have and found zero difference in terms of performance ( same 2 day usage ) decided to flash my device with JM5 and used it w/o a lag fix for 2 days, notice a very slight improvment on how fast the inbox/contacts can open and then did a fresh flash with lagfix 2.x installed I didnt NOT notice any performance difference but I am always open and welcome to any lagfix that is stable,safe and fast ( in that order ) right now I have JG8 installed w/o lag fix and its very snappy, I still want to install a lag fix for this even if i dont see/feel any performance difference at all.. thats just me.. Now im wondering w/c lag fix is the most stable and safe.. stability/safty > speed
EDIT:
Also I believe it could be possible that certain versions of lagfixes work better with certain versions of firmware also, its all about getting the perfect combination.. altho my question still stands on w/c is the safest lagfix heheheh

Well actually i gave up on benchmarks.
To me the whole user experience is more important. If apps open instantly and the phone runs smooth then it's fine with me. I did notice some firmwares are better then other ones.
Right now i'm running JM1 (rev 3) with CFLagFix1.80 installed which makes the phone very stable and running smoothly so right now i'll stick to this firmware until a proper GPS fix is released or until Froyo is released.

Phandroid said:
*raisehand*
Predictable steps to demonstrate a difference:
1. Use 2 SGS, firmware of your choice
2. One with, say, 1 Click Lag Fix - the other one stock
3. Now for the test, perform simultaneously:
3.1. Open Market and go to "Downloads", update an app, close.
3.2. Open Contacts, quickly switch to favourites, dial Number. Drop call. Exit.
3.3. Open Messaging, conversation of your choice, quickly switch the writing language, write, send, exit.
3.4. bla bla goanforeva
Now if you don't notice an improvement there and in many other cases you most certainly have done something wrong.
If you are saying people are just being placebo-ed you are implying that everybody else besides you is unable to tell a real difference. Think about it, maybe it's the other way around.
Click to expand...
Click to collapse
Lol I think you didn't understand my question... I'm sure that these lag fixes all work, no doubt about that. But which of them is faster? For that i can't rely on quadrant i'm sure...

Poll: Do you use JIT or not?

Simple poll. I am curious to see who uses JIT and who has it disabled? If you answer, please explain why you do or do not use JIT. Just thought I would get people's different input on this

i used to have it enabled but had seen no positive outcomes, just more lag.
but that was when i was running CM6... i havent tried it on CM7 yet.

I know JIT on Sense 2.1 was disastrous for the most part. Have stayed away from it for the most part.
JIT on CM7 is actually very stable, however I observe absolutely no improvement or noticeable change in performance anywhere.
Then again, people also claim a smoother experience when "Allow purging of assets" is unchecked, even thought it is meant to improve performance of low memory devices like ours... YMMV, I guess.

My question is, what are the supposed benefits? Scoring higher on a particular benchmark score and thats it? I agree. It doesn't seem to make my phone any smoother, if anything, it makes it more laggy.

I've been using jit since the days of Ic3 rom and damage's roms as well. I think it just improves data. No speed on the phone just how the phone complies data. I think. But from my time on here if you can't overclock to 768 and run stable then I'd recommend avoiding jit.
Yea its Me Again With The
Modified Hero

In aosp 2.2 I would get an extra 20 or so on my quadrant score with JIT enabled. In gingerbread I haven't seen any improvement at all. I leave it disabled because I heard it uses more ram to speed things up.

I use JIT and I always have since installing custom ROM images. There's a lot of hearsay left over from long before I joined xda-developers that says it causes instability. But this is probably more to do with the original way JIT was brought to the Hero.
The latest official software for the Hero is built from Android 2.1. JIT was not introduced into Android until 2.2. So as far as I know, the original method to implement JIT on the Hero was to hack it into the official software. This is likely where the instabilities were found.
I've been using JIT since dabbling with CM6 (and its derivatives), and I've never seen any negative effects. I do, however, always decrease my VM heap to 24m and enable compcache at 18% when using JIT. Not doing so MAY cause JIT to starve the phone of memory, which could be another source of the instabilities you've seen mentioned.
Some people say JIT isn't necessary because its effects are only noticed in benchmarks such as Linpack. This, simply put, is false. JIT is always going to offer a performance increase. Now, depending on how you use your phone, the increase may not always be very noticeable, but that doesn't mean it's not there. And the less time the VM spends using the processor, the more battery life you're going to see. That's an angle that isn't always addressed when JIT is discussed.
My advice is to leave it enabled as long as you don't specifically see any issues with it. Our sister phone of sorts, the Droid Eris, now has it enabled by default in CM7.

Thanks jasonmaloney, I always prefer hearing answers from people with technical know-how such as yourself. On a CM performance related note, what is your opinion on people reporting better performance with "Allow purging of assets" disabled?

c00ller said:
Thanks jasonmaloney, I always prefer hearing answers from people with technical know-how such as yourself. On a CM performance related note, what is your opinion on people reporting better performance with "Allow purging of assets" disabled?
Click to expand...
Click to collapse
I was actually the one who submitted the patch to enable it by default. I've only ever heard of specific issues in relation to ADWLauncher, which, in my opinion, shouldn't ever be used in the first place due to the numerous better-written alternatives.
But I'm starting to wonder whether it has anything to do with the GPS problems people have been seeing.
All I really know for sure is that the graphics subsystems in CM7 for the Heroc are screwed up, and that they're probably going to be that way even when CM7 is finalized.
EDIT: If anyone can find compelling evidence that having it enabled is causing issues, I'll revert the patch and make it disabled by default.

jasonmaloney said:
All I really know for sure is that the graphics subsystems in CM7 for the Heroc are screwed up, and that they're probably going to be that way even when CM7 is finalized.
Click to expand...
Click to collapse
Is that a good or bad thing? Yes the words used dictates it's meaning, but what would have been the plus factors if it were squared away?

oohaylima said:
Is that a good or bad thing? Yes the words used dictates it's meaning, but what would have been the plus factors if it were squared away?
Click to expand...
Click to collapse
The most glaring example of a problem is seen in running Neocore. None of the textures show up.

EXT4 worth it?

Hi, so after cm rooting i noticed there is also an ext4 upgrade...is this worth it and will I have data lose during the change? Im on 2.3.3 and am wondering if it is really worth it! Ed

are you kidding me?
besides that this post should not even be in this forum (try Q & A) there are hundreds of other posts and threads discussing this topic if you only use your -(0-0)- !

Yes and no
It may have some advantages but as for what I'm not sure but as for nay major advantages I would say no. I'm still using EXT2 and my benchmarkes are still 1900+. I've tried almost all the other lagfixes and found no real advantage. The only thing I hate about custom kernels with lagfix is the secondary samsung splash screens and custom splash screen. They kill the post time.

I would say it isn't as worth it as what people say. First thing most people do after converting their filesystem is run quadrant. It's possible that improved quadrant scores don't translate to real world performance though.
Even worse, running quadrant actually engages the placebo effect so you walk in with a more positive impression. Meanwhile, I don't recall ever seeing anyone from the EXT4/EXT2 i9000 community running blind tests, and neither development community has actually shown any evidence formal testing has been performed. All the arguments seem to be based around quadrant and PC testing. If methods like this were applied to clinical testing, every drug would pass
Honestly, give both a try, but do it blindly.
Why Quadrant may be wrong
This is just a bit of background why Quadrant's scores may not reflect real life performance. Until we check the actual ratio's of Quadrant, and compare with actual usage ratio's though, we can't identify how "real" it's scores are.
Consider a benchmark which produces 1 final score. It may be calculated by:
[MAX TIME - Time to read 1000mb] + [Max time - time to write 1000MB]. In this case, both scores contribute to 50% of the final score, which can be worth 2x MAX Time.
Scenario 1: Time to read/write is both the same
Scenario 2: Read time is 1% shorter than Scenario 1, but write time is 1% longer. Both will have the same score in Quadrant..
Scenario 3: Read time is 5% longer than Scenario 1, but write time is 50% shorter. Scenario 3 will get the best score
Which one is ACTUALLY faster though. The benchmark-toting individuals will claim Scenario 3 is faster, because of the score. HOWEVER, that may be incorrect. Consider the following:
If a user reads 100x more data than they write:
1) Clearly, faster read scores are more important.
2) The BEST filesystem will be Scenario 2, despite being equal last.
3) Scenario 1 will be mid place
4) The scenario with the best score, will actually have the WORST performance.
5) A drop in 1% read performance would need a HUGE increase in write performance to actually be faster.
Until we have an idea of how accurate Quadrant REALLY is, run your own tests, and do so without knowing which filesystem is running. High quadrant scores may boost your e-penis size, but as you can see, it is theoretically possible for the scores which are produced to score slower performing filesystems more highly than faster ones. Disappointingly though, a decreasing number of users/developers at XDA these days are actually interested in the truth, and simply in not being wrong.
Even worse, the community for some reason seems VERY anti-RFS, and wont give it a chance regardless. It might be a LOT better than it used to be. Either way, it seems to be good enough for me.
Ignore the theatrics and run a blind test. That's the only way to determine what is ACTUALLY faster.

monkeytennis said:
Hi, so after cm rooting i noticed there is also an ext4 upgrade...is this worth it and will I have data lose during the change? Im on 2.3.3 and am wondering if it is really worth it! Ed
Click to expand...
Click to collapse
I guess you mean CF root right? Will just answer the data loose question. No you shouldnt. But do a backup before. Its fast and easy (if you are on CF root that is)
If its worth depends on you? You experience any lag on rfs? Phone slow?
ramrod54 said:
It may have some advantages but as for what I'm not sure but as for nay major advantages I would say no. I'm still using EXT2 and my benchmarkes are still 1900+. I've tried almost all the other lagfixes and found no real advantage. The only thing I hate about custom kernels with lagfix is the secondary samsung splash screens and custom splash screen. They kill the post time.
Click to expand...
Click to collapse
@ramrod54 , where did you get ext2 support on JVK? And what the?
What samsung splash screens and custom splash? What rom and kernel are you on? And what lagfixes? And we both know quadrant score doesnt matter does it ?

Yes, it's worth it. Some things (Android Market, Gmail) works really MUCH faster then on rfs.

Unrealwolf said:
Yes, it's worth it. Some things (Android Market, Gmail) works really MUCH faster then on rfs.
Click to expand...
Click to collapse
Hrm, I've never noticed a difference. Market is slow on any room, hell market.android.com is slow too. Gmail always worked fast for me, on any rom.
Personally, I don't see or feel the point in using anything but rfs, but I suppose if someone has half a bazillion apps installed, then maybe an alternative filesystem might be better.
I say try it. If you notice a difference, good for you. If you don't, then stick with rfs.

What about battery performance ? from what I have read, battery performance is also better with RFS.

I always use ex4, its not as needed now on gingerbread but I just prefer the file system...it is better than RFS...but RFS has improved a great deal so you may not noticed that much difference, the rom may become a little smoother..You wont get data lose because of ex4, maybe the way the kernel is built...dont forget that 2.3.3 gingerbread is still beta and without the source code for the kernel you cant expect great things yet, although chainfire has done some amazing work and now we can change the file system using his app....works really well.
Also regarding battery, the difference in performance is such a small margin that its not even an issue.
What alot of people aren't aware of is that the Nexus S for example uses ex4 file system as default straight out of the box
Its not just a lagfix for the galaxy s, its a very good file system too...
Just a side note on Quadrant, ex4, ex2 will trick the app...if you buy the pro version, you will see how much the file system stretches on the bar...Quadrant is more for fun....or HTC

Think it´s worth cause rfs slow down your system after a while