Is 2.2 really faster?


Last Updated:

  1. supermatt9

    supermatt9 Member This Topic's Starter

    Joined:
    Apr 14, 2010
    Messages:
    19
    Likes Received:
    0
    So I've pretty much spent the entire weekend installing and uninstalling 2.2 on my droid. This afternoon I got it setup so that it was running SUPER smooth.

    Before 2.2 my Quadrant score was about 605 (running BB1.1 oc to 1ghz). With 2.2 I was getting about 1200 in quadrant (oc'ed at 1ghz as well).

    I then compared my phone with my brothers (his is setup exactly how mine was before 2.2) and while my phone was a bit snappier scrolling through home screens and opening the app drawer, when it came to opening programs - his droid opened the programs faster than mine did.

    What is that all about? Anyone have any thoughts? Both phones were freshly rebooted.

    thx
     

    Advertisement
  2. nstallion

    nstallion Well-Known Member

    Joined:
    Nov 13, 2009
    Messages:
    1,152
    Likes Received:
    136
    Bugless Beast was an optimized ROM that Pete spent a lot of time making smooth and fast. The leaked 2.2 ROM is exactly that, a leaked, unfinished version from Motorola. Once the ROM developers have their hands on the source code for 2.2 you can expect even better performance.
     
    PerCompLLC likes this.
  3. xmr405o

    xmr405o Well-Known Member

    Joined:
    Dec 7, 2009
    Messages:
    4,171
    Likes Received:
    1,185
    Yeah, I've been doing the same thing. I've uninstalled and reinstalled 2.2 because I had issues with my browser and other apps running slower than I am used to. Especially, auto rotating is so slow and it bugs the heck out of me. I couldn't take it anymore so I went back to my super fast NexBeast ROM. Linpacks aren't up to par with 2.2 but those numbers don't really mean anything if you're phone still lags.
     
  4. d-man

    d-man Active Member

    Joined:
    Dec 23, 2009
    Messages:
    25
    Likes Received:
    2
    That is an expected result of the JIT compiler: The system is optimizing the app's code as it starts up. After a couple of times the startup time should be nearly back to normal, but will never be as low as the pre-JIT times.

    The trade-off is: you get longer initial startup times, but everything runs faster and takes less memory. And with Android, the things you use most tend to stay running in the background, so that initial startup only happens once.
     
  5. Bunsen Honeydew

    Bunsen Honeydew Well-Known Member

    Joined:
    Nov 14, 2009
    Messages:
    275
    Likes Received:
    33
    My phone typically runs faster the longer it has been since a reboot on 2.2. I can't wait for pete to get done with his 2.2 rom though.
     
  6. esmith818

    esmith818 Well-Known Member

    Joined:
    Nov 15, 2009
    Messages:
    691
    Likes Received:
    316
    I don't know what any of the testing apps really mean, but I figure they serve good enough for comparing apples to apples. When I ran Linpack with stock 2.1 I was getting an average of 3 MFLOPS. With a rooted phone running NexBeastV1.1 OCd to 1 GHz I was in the 8-9 MFLOPS range. Now with 2.2 running at 1 GHz, I'm in the 15-16 MFLOPS range.

    I have no idea what an MFLOP is or how it is measured, or what it means, but I am happy to see that my phone is running 5x faster than stock.

    Of course, with Quadrant, I'm falling just below the NexusOne with Froyo as opposed to several other posts here about being at the top of the list. While I'm on board with the philosophy that comparisons are not that important, I'd still like to know what I need to be tweaking to match my peers. No one likes being the "smallest" guy in the gym showers. :D
     
  7. PerCompLLC

    PerCompLLC Well-Known Member

    Joined:
    Dec 20, 2009
    Messages:
    521
    Likes Received:
    128
    Now THAT is FUNNY!!!!
     
  8. meek_reese

    meek_reese Well-Known Member

    Joined:
    Jan 12, 2010
    Messages:
    70
    Likes Received:
    15
    I haven't had a chance to compare my (2.2) phone next to a 2.1 phone, but just playing with the phone, it seems soooo much faster than even BB 1.1. I was running BB1.1 at 1GHz and loved it. Now I'm running 2.2 at 1.2GHz and the thing absolutely flies. Even over 3G, web pages seem to open almost instantaneously. On mobile optimized websites, I don't even notice a loading time whatsoever. I don't have wi-fi at home anymore, so I haven't really had a chance to try that, but i can only imagine that it is super fast too. I'm also running ADW launcher, and scrolling/opening apps seems to run sooooo much better than BB1.1.
     
  9. flash24

    flash24 Well-Known Member

    Joined:
    May 14, 2010
    Messages:
    91
    Likes Received:
    2
    Browsing speed is definitely faster and so is the camera.
     
  10. mtbhk44

    mtbhk44 Well-Known Member

    Joined:
    Nov 9, 2009
    Messages:
    363
    Likes Received:
    38
    I have not found either of these. I find browsing to be very slow and laborious. I have also found Flash video (Hulu in particular) to be VERY choppy and basically unusable. I have also found the phone to be

    I put Froyo on my phone without wiping (yeah, I know, I GOT it!). Wiping and reinstalling as we speak. Hopefully this clears up all of my issues.
     
  11. Darth_Penguin

    Darth_Penguin Well-Known Member

    Joined:
    Nov 7, 2009
    Messages:
    65
    Likes Received:
    5
    I didnt do a wipe when I went from Nexbeast to 2.2 and the phone has never felt faster. I can only imagine how much better the phone will feel once we get some matured roms. As it stands, 2.2 has been the single fastest rom I have used to date. Its actually been so smooth that I downclocked the OC to 800mhz from the typical 1ghz because I don't think it needs it.
     
  12. ech0

    ech0 Active Member

    Joined:
    May 30, 2010
    Messages:
    35
    Likes Received:
    12
    With LauncherPro instead of the standard launcher 2.2 is the fastest ROM I've ever had installed.

    One thing to keep in mind: Hulu is not designed, nor is it meant to be played on Flash. Keep in mind 2 things: 1.) Flash is in beta, and for what it is it performs very well, and 2.) You have to actually make a work-around in order to even watch Hulu on your phone, so Hulu is not an accurate judge of the phone's performance.

    If you installed the ROM and you're having performance issues, and you have NOT rebooted it yet, try rebooting the phone. When I installed, waited for everything to sync, and then rebooted, everything was then working damn smooth.
     
  13. esmith818

    esmith818 Well-Known Member

    Joined:
    Nov 15, 2009
    Messages:
    691
    Likes Received:
    316
    Agreed. By a long shot.
    Also, Flash (especially hulu/video) involves a lot of data streaming. Viewing hulu was never designed for compatibility with a 3G connection.
     
  14. Fabolous

    Fabolous Superuser VIP Member

    Joined:
    Nov 7, 2009
    Messages:
    3,635
    Likes Received:
    2,126
    Also, keep in mind the Flash 10.1 beta out right now has no hardware acceleration, meaning it only uses the CPU, and not the GPU (which was built for this stuff)

    Also, MFLOPS = Mega FLOPS = Million floating point operations

    So our Froyo Droids are doing 15 million floating point operations per second
     
  15. BucYouUp68

    BucYouUp68 Well-Known Member

    Joined:
    Nov 10, 2009
    Messages:
    373
    Likes Received:
    27
    MIPS (the company name): It is unfortunate that the term MIPS is used as a processor benchmark as well as a shorthand form of a company name, so first I better make the distinction clear. The company responsible for the CPU designs in the N64 is MTI, an abbreviation for MIPS Technologies Inc., but many people (incuding myself) refer to the company as just MIPS.

    MIPS (the benchmark):
    The processor benchmark called MIPS has nothing to do with the company name. In the context of CPU performance measurement, MIPS stands for 'Million Instructions Per Second' and is probably the most useless benchmark ever invented. The rest of this page concerns MIPS as a benchmark, not the company (also discussed here are the MFLOPS and SPEC benchmarks, plus a comment on memory bandwidth).
    The MIPS rating of a CPU refers to how many low-level machine code instructions a processor can execute in one second. Unfortunately, using this number as a way of measuring processor performance is completely pointless because no two chips use exactly the same kind of instructions, execution method, etc. For example: on one chip, a single instruction may do many things when executed (CISC = Complex Instruction Set Computing), whereas on another chip a single instruction may do very little but is dealt with more efficiently (RISC = Reduced Instruction Set Computing). Also, different instructions on the same chip often do vastly different amounts of work (eg. a simple arithmetic instruction might take just 1 clock cycle to complete, whereas doing something like floating point division or a square root operation might take 20 to 50 clock cycles).
    People who design processors and people like me who are interested in how they work, etc., almost never use a processor's 'MIPS' rating when discussing performance because it's effectively meaningless (like many people, I did at one time used to think that a CPU's MIPS rating was all important. Ironically, an employee at MIPS Technologies Inc. corrected my faulty beliefs when I asked him about the performance of the R8000.
    MIPS numbers are often very high because of how processors work, but in fact the number tells one absolutely nothing about what the processor can actually do or how it works (ie. a processor with a lower MIPS rating may actually be a better chip because its instructions are doing more work per clock cycle). There are dozens of different processor and system benchmarks, such as SPEC, Linpack, MFLOP, STREAM, Viewperf, etc. One should always use the test that is most relevant to one's area of interest and the system concerned. With games consoles, however, this is a bit of a problem because no one has yet made a 'games console' benchmark test - people have to use existing benchmarks which were never designed for the job.
    An example: imagine a 32bit processor running at 400MHz. It might be rated at 400MIPS. Now consider a 64bit processor running at 200MHz. It might be rated at 200MIPS (assume a simple design in each case). But suppose my task involves 64bit fp processing (eg. computational fluid dynamics, or audio processing, etc.): the 32bit processor would take many more clock cycles to complete a single 64bit fp multiply since its registers are only of a 32bit word length. The 32bit CPU would take at least twice as long to carry out such an operation. Thus, for 64bit operations, the 32bit processor would be much slower than the 64bit processor. Now think of it the other way round: suppose one's task only involved 32bit operations. Unless the 64bit registers in the 64bit CPU could be treated as two 32bit registers, the 32bit CPU would be much faster. It all depends on the processing requirements.
    The situation in real life is far more complicated though, because real CPUs rarely do one thing at a time and in just one clock cycle. Simple arithmetic operations may take 1 cycle, an integer multiplty might take 2 cycles, a fp multiply might take 5 clock cycles, a complex square root operation in a CISC design take 20 cycles, and so on. Worse, some CPUs are designed to do more than one of the same kind of operation at once, ie. they have more than one of a particular kind of processing unit. CPUs such as SGI's R10000 series (or later equivalents), the HP PA8000 series, the old Alpha 21x64 series, etc. often have 2 or more integer processing units, multiple fp processing units and at least one load/store unit. Sometimes, they may have special units too, for example to accelerate square root calculuations.
    But it doesn't stop there! Today, there are technologies such as MMX (from Intel) which is designed to allow a 64bit integer register to be treated as multiple 32bit, 16bit or 8bit integer registers, and also MDMX (from MIPS Technologies Inc.) which does the same but is more powerful in that it also allows the same register splitting to be done with fp registers and includes a 192bit accumulator register, although at present SGI hasn't implemented MDMX in any of their available CPUs. These new ideas enable many more calculations to be performed in the same amount of time compared to older designs. An example: Gouraud shading involves 32bit fp operations; using a 64bit fp register as two 'separate' 32bit fp registers will (at best) double the processing ability of the CPU.
    So that's the MIPS benchmark dealt with, ie. it's useless, so ignore it. Since I mentioned fp calculations, that leads nicely onto the MFLOPS benchmark.

    MFLOPS
    People often mean MFLOPS to mean different things, but a general definition would be the number of full word-size fp multiply operations that can be performed per second (the M stands for 'Million'). Obviously, fp add or subtract operations take less time and slowest of all is fp divide. Older CPUs take many clock cycles to complete one FLOP and so, even at a high clock speeds, their FLOP rate can be low. An example is the 486DX4/100 which is rated at about 6MFLOPS. Compare this to the 200MHz R4400 which is rated at about 35MFLOPS. For older processors, clock speed is clearly no indication of MFLOP rate.
    Newer designs don't mean things become clearer - if anything the situation is more complex, since the situation is often the reverse: CPUs like the R10000 can do two fp operations each clock cycle, giving it a rating of 400MFLOPS at 200MHz. The R8000 is even more confusing since it has two fp execution units, each capable of doing two fp ops/clock, giving it a rating of 360MFLOPS at 90MHz! (that's ten times faster than an Intel P90).
    Again, the nature of the task is important. A 64bit CPU that can do 400MFLOPS may be fine, but if one's work only needs 32bit processing then much of the CPU's capabilities are being wasted. CPUs like the R5000 address this problem, aiming at markets that do not need 64bit floating point (fp for short) processing. Future designs like MDMX will solve the wastage problem, but it will also make the measuring of CPU performance even harder. Perhaps CPU capability is a better metric, but no one has devised such a test yet. There are just a wide variety of benchmarks and one must use the most appropriate test as a basis for decision making.
    All this talk of MFLOPS is fine, but it misses one very important point: memory bandwidth. A fast CPU may sound impressive, and PR people will always talk in terms of theoretical peak performance, etc., but in reality a CPU's best possible performance totally depends on the rate at which it can access data from the various kinds of memory (L1 / L2 cache and main RAM). A fast CPU in a system with low memory bandwidth will not perform anywhere near its theoretical peak (eg. 500MHz Alpha). I have studied the effect of this on the 195MHz R10000 and the results are very interesting. If you want to know more about the whole issue of memory bandwidth, then see STREAM Memory Bandwidth site.
    What is important here with regard to the N64 is that SGI have given it a very high memory bandwidth indeed (500MB/sec peak, ie. almost 4 times faster than PCI). The N64's memory design uses Rambus technology, which is also used in SGI's IMPACT graphics technology.

    SPEC
    I've always found it funny (or annoying, depending on my mood at the time :) that gamers try and use the SPEC benchmark when arguing about the performance of main controller CPUs in games consoles. What gamers should understand is that SPEC's main CPU test suite (currently SPEC2000) was never designed for games consoles; SPEC is not a graphics test, or a test designed to measure the preprocessing tasks often needed for 3D graphics, such as excessive MADD (multiply-add) operations, although some individual tests in the test suite may be similar.
    SPEC (92, 95 or 2000) is an integer/floating point test package consisting of a number of separate integer and fp tests which are supposed to be run on systems with at least 32MB (SPEC92) or 64MB (SPEC95) of RAM (perhaps more for SPEC2000). Thus, it's fine to discuss theoretical SPEC performance of a CPU like the R4300i, but in the context of a games console it's completely meaningless. This is why you won't find my N64 tech info site using the theoretical SPEC numbers for the R4300i in my own discussions because they are useless when talking about the N64's real capabilities.
    While I'm on the subject, please note the following:


    • One cannot convert SPEC92 results to SPEC95 results in any kind of linear manner. The same applies to SPEC2000.
    • All SPEC test suites consist of a weighted average of many different tests and as such any wide variance in test results can be seriously hidden (as is the case with the R5000). SPEC focuses more on scientific and engineering applications - such tasks are not like 3D graphics and so are not helpful when judging CPU performance (many SPEC tests involve 64bit operations, whereas geometry and lighting calculations in a games console will usually be 32bit operations).
     
    droidftw and flash24 like this.
  16. UBRocked

    UBRocked VZW Nexus Please!!! VIP Member

    Joined:
    Jan 31, 2010
    Messages:
    4,335
    Likes Received:
    1,563
    That's a big post! :D

    I will add this, apps that take a lot of the phone's resources like games run so much faster. Play a nice game and pay attention to how much less time the phone spends loading (not a free version of tic-tac-toe from the market...a real game like Asphalt, Raging Thunder, etc.). Home Run Battle for example loads so fast and that white Com2Com screen used to stay on my phone for about 20 seconds before the game started. Much faster now! I haven't seen a big improvement in actual gameplay...but it was good to begin with so I wasn't expecting much in terms of improvements there.

    Bottom line...yeah it's faster :)
     
  17. mrthundercleese

    mrthundercleese Well-Known Member

    Joined:
    Nov 20, 2009
    Messages:
    187
    Likes Received:
    2
    Thats because of the JIT :).

    The JIT compiler optimizes the code as it runs, sacrificing a little memory for performance. A reboot makes it start over (unless Dalvik is different than other JRE's).
     
  18. inssane

    inssane Well-Known Member

    Joined:
    Dec 17, 2009
    Messages:
    1,851
    Likes Received:
    156
    BucYouUp68
    Love your sig...looks familiar
    QUOTE=inssane;858707]The search button must be broken again :p[/QUOTE]

    I am glad we are on the same page!

    Regarding 2.2 - it's very SMOOTH, I think that's the best word.
    Faster, eh, smoother is better and it is a bit quicker at 1200 but nothing ground breaking.
    Most stable for me = NexFro
     
  19. johnlgalt

    johnlgalt Antidisestablishmentarian VIP Member

    Joined:
    Oct 28, 2009
    Messages:
    9,416
    Likes Received:
    1,919
    All I can say is - yes. The initial slightly longer loading time is nothing compared to the running time of hte application at hand.

    I am still testing, but things like Market and browsing are definitely faster - as is the camera, going into and coming out of sleep, app drawer reload and application population (launcherPro, so that is really not a fair comparison), and even account synchronizing and social media (Twitter, MySpace and FaceBook).
     
  20. mtbhk44

    mtbhk44 Well-Known Member

    Joined:
    Nov 9, 2009
    Messages:
    363
    Likes Received:
    38
    I wiped, wiped, wiped, wiped and then put the ROM back on. It's flying now. I also did not re-install my apps from Titanium. I think that was causing problems. I hope it continues to impress.
     
  21. xmr405o

    xmr405o Well-Known Member

    Joined:
    Dec 7, 2009
    Messages:
    4,171
    Likes Received:
    1,185
    Yeah it took a couple of tries with different ROMS. I finally got 2.2 to play nice. There's still issues with my internet browsers. Dolphin and xScope doesn't perform as they should on 2.2. It's a little laggy and I'm not just talking about flash sites.
     
  22. jgkelly

    jgkelly Well-Known Member

    Joined:
    Nov 28, 2009
    Messages:
    63
    Likes Received:
    3
    I used birdman 2.2 when it came out. It is not as smooth as fabs nextheme 2.2. Fastest rom ive ever had and smooth too. I went to verizon store to maybe get a inc, since i got 2.2 the inc is not inc. my droid was faster to me.
     
  23. rjoudrey

    rjoudrey Well-Known Member

    Joined:
    Nov 5, 2009
    Messages:
    1,440
    Likes Received:
    125
    Switched to the 1.2 Kernel (running at 1.1) from the 1.0 Kernel (running at .9) and there is a significant diference. I have also noticed that flash content on web pages causes quite a bit of lag in the browser.
     
  24. rjoudrey

    rjoudrey Well-Known Member

    Joined:
    Nov 5, 2009
    Messages:
    1,440
    Likes Received:
    125
    All sites seem to have some flash content. I get the same lagging.
     
  25. GorillaTheHutt

    GorillaTheHutt Well-Known Member

    Joined:
    Nov 17, 2009
    Messages:
    227
    Likes Received:
    40
    i reinstalled my apps using Ti and am using Birdman's froyo with a 1.1 GHz kernel. i feel like everything is more snappy in 2.2. i'm usually very skeptical of claims like that since it's usually a placebo effect, but after over a day of use i'm still surprised by how fast things open/close/switch sometimes, so i think it's real.
     

Share This Page

Loading...