Jump to content

28 Jul Fr19: MoDaCo Custom ROM for the LG Optimus 2X with Online Kitchen (new: custom kernel)


Recommended Posts

Guest Paul
Posted

I would advise restoring your backup and waiting for the Fr16 release...

P

Guest wc326
Posted (edited)

Rf16 beta4

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

64ram hack

SQLite unclick for better performance.

1GHZ cpu stock.

Baked with:

Only google Apps.

None LG apps , besides the LG gallery.

Quadrant score 1st run: 3230

2nd run: 3320

3rd run: 3340

it is getting better and better LOL

Edited by wc326
Guest aaww
Posted

How many mV should the phone read for the fully charged battery ???

Mine shows 4115mv and displays 100% but then keeps on charging. now it is 4123mv already but shows 99% after I unplugged the charger.

It doesn't make any sense.

I am on Fr16 Beta4 no 64mb hack and some apps removed(widgets, live wallpapers) other than that it is a very standard selection and also cache wiped after upgrading from beta 2.

Guest ascito
Posted
Rf16 beta4

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

64ram hack

SQLite unclick for better performance.

1GHZ cpu stock.

Baked with:

Only google Apps.

None LG apps , besides the LG gallery.

Quadrant score 1st run: 3230

2nd run: 3320

3rd run: 3340

it is getting better and better LOL

So Revert SQLite Library to Stock must be unchecked to have better performance?

Guest wc326
Posted (edited)
So Revert SQLite Library to Stock must be unchecked to have better performance?

isn't that supposed to be like that??

i am not 100% sure tho. to be honest i dont' even know what that is :unsure:

all i see is that when it is clicked.

This option disables the SQLite 'speed tweak' , which i only know what speed tweak is all about. but totally not sure what it does anyways.

Edited by wc326
Guest soundsk
Posted

Yes - better performance, but not so safe.

Cheers!!

So Revert SQLite Library to Stock must be unchecked to have better performance?
Guest wc326
Posted
Yes - better performance, but not so safe.

Cheers!!

what is the result of not being safe???

crash data lost, or something even more extreme?

Guest djmcnz
Posted
Yes - better performance, but not so safe.

Cheers!!

To put this in context...

I have also had a database corruption but found it was very easy to fix so therefore consider the performance boost outweighs the consequences.

In my example my Exchange (email) database got corrupted and the Exchange client would not open. Logcat showed a SQLite database access problem (corruption). All I needed to do was 'clear data' for my Email app and re-sync. This forced the recreation of the db.

I've not had other problems since but expect if/when I do the solution will be just as easy.

YMMV

Guest toti1001
Posted
How many mV should the phone read for the fully charged battery ???

Mine shows 4115mv and displays 100% but then keeps on charging. now it is 4123mv already but shows 99% after I unplugged the charger.

It doesn't make any sense.

As i know, 4200mv is optimal. Mine goes at 100% to 4190mv, but when i unplugged the charger, it goes down in 1 minute to 98%. I use Battery Calibration from Market but with the same result.

Guest MeX_DK
Posted
I have also had a database corruption but found it was very easy to fix so therefore consider the performance boost outweighs the consequences.

I think the problem might arrise when your database corruption suddenly spreads to your online accounts, ie that the corrupted data gets imported, and corrupts the data stored online. Not saying its likely to happen, just saying its an avenue that "could" happen.

But strickly speaking, how much of of a performance gain would someone be looking at comparing Stock SQL, and the SQL fix?

Guest masi0
Posted
As i know, 4200mv is optimal. Mine goes at 100% to 4190mv, but when i unplugged the charger, it goes down in 1 minute to 98%. I use Battery Calibration from Market but with the same result.

Have the same both stock and Mcr16 which I think is completely normal. Same issues happens to SGS or even HTC Desire with Ginger.

Also - do not thrust battery meter. Anyway Android battery meter is more accurate than in iOS - you cannot have 100% battery for hours, after unplugging the charger - it should immidiately drop to 99% anyway :unsure:

Guest djmcnz
Posted
I think the problem might arrise when your database corruption suddenly spreads to your online accounts, ie that the corrupted data gets imported, and corrupts the data stored online. Not saying its likely to happen, just saying its an avenue that "could" happen.

But strickly speaking, how much of of a performance gain would someone be looking at comparing Stock SQL, and the SQL fix?

Table integrity, rather than data integrity is the main concern as I understand it and actual data loss is quite unlikely. It's still a risk though.

Anecdotaly, using a sample of one, between 50 and 100% db io improvement.

Guest wc326
Posted
Table integrity, rather than data integrity is the main concern as I understand it and actual data loss is quite unlikely. It's still a risk though.

Anecdotaly, using a sample of one, between 50 and 100% db io improvement.

what is db io improvement.

Guest Trym Hansen
Posted
i am not 100% sure tho. to be honest i dont' even know what that is :unsure:

all i see is that when it is clicked.

This option disables the SQLite 'speed tweak' , which i only know what speed tweak is all about. but totally not sure what it does anyways.

The SQLite speed tweak is a 'hack' to improve benchmark scores.

It does this by not flushing every commit to storage, in non-geek that means it keeps information in RAM instead of writing it to flash right away. This way benchmarks can store 2000 entries in a second instead of 20.

However... the information has to be written to flash sooner or later anyway. In everyday usage, you would not notice if an app takes 0.01 or 0.1 seconds to store a database entry. What you *will* notice is when the system suddenly takes a second or two two write data it has cached in RAM, when that RAM is needed for something else.

Also, as previously mentioned, when data is kept in RAM, if the phone reboots or locks, that information is lost, and the database potentially corrupted.

On a desktop computer, caching techniques like this are used all the time, and provides for a much better desktop-experience, since it has more ram, more processor power, and not least, more data to handle.

On a phone, you get the oppsite result, as the phone suddenly lags when you don't expect it to.

SQLite is the heart of Android storage, pretty much everything is stored in a database, including contact lists, e-mails and such. By using the tweak, which, I repeat, you can only notice in benchmarks, you're playing roulette with that information, especially with a phone which is known to spontaneously combust...er...reboot.

Unless you use your phone for some very specialized, data-base heavy apps, there is absolutely no advantage to applying the hack/tweak.

::Trym

Guest djmcnz
Posted (edited)
what is db io improvement.

DataBase Input/Output.

How quickly it can (edit for clarification:) "[virtually]" read and write data see this post by Trym Hansen for a fuller, easy to understand and generally better explanation.

Edited by djmcnz
Guest wc326
Posted
The SQLite speed tweak is a 'hack' to improve benchmark scores.

It does this by not flushing every commit to storage, in non-geek that means it keeps information in RAM instead of writing it to flash right away. This way benchmarks can store 2000 entries in a second instead of 20.

However... the information has to be written to flash sooner or later anyway. In everyday usage, you would not notice if an app takes 0.01 or 0.1 seconds to store a database entry. What you *will* notice is when the system suddenly takes a second or two two write data it has cached in RAM, when that RAM is needed for something else.

Also, as previously mentioned, when data is kept in RAM, if the phone reboots or locks, that information is lost, and the database potentially corrupted.

On a desktop computer, caching techniques like this are used all the time, and provides for a much better desktop-experience, since it has more ram, more processor power, and not least, more data to handle.

On a phone, you get the oppsite result, as the phone suddenly lags when you don't expect it to.

SQLite is the heart of Android storage, pretty much everything is stored in a database, including contact lists, e-mails and such. By using the tweak, which, I repeat, you can only notice in benchmarks, you're playing roulette with that information, especially with a phone which is known to spontaneously combust...er...reboot.

Unless you use your phone for some very specialized, data-base heavy apps, there is absolutely no advantage to applying the hack/tweak.

::Trym

thank you so much on your respond!! great reply.

Guest aaww
Posted
Have the same both stock and Mcr16 which I think is completely normal. Same issues happens to SGS or even HTC Desire with Ginger.

Also - do not thrust battery meter. Anyway Android battery meter is more accurate than in iOS - you cannot have 100% battery for hours, after unplugging the charger - it should immidiately drop to 99% anyway :unsure:

well it was like that on Fr12 for me. ever since Fr16 Beta2 i can disconnect my phone and it keeps 100% for a few minutes.

Now that i did a full wipe it is working grate. i will see how much the phone looses over night standby tonight but from my perspective the device feels very snappy and smooth and the battery is waaaaaaay better than it was on stock or on any other Fr-xx.

cheers

Posted
The SQLite speed tweak is a 'hack' to improve benchmark scores.

...

::Trym

Really good explanation ... Really appreciated!

Guest djmcnz
Posted
Unless you use your phone for some very specialized, data-base heavy apps, there is absolutely no advantage to applying the hack/tweak.

Although I wouldn't characterise it as specialised, large Exchange databases benefit appreciably from this mod in day to day use. I also find a small but perceptible benefit in managing large music libraries (> 16GB so perhaps specialised). So I think that there some valid use cases that are more common than you elude to.

Nevertheless good answer, makes my phone-on-a-tram reply immediately after yours look pretty dumb! lol. :unsure:

Guest PhilNelwyn
Posted
Same here, the battery is still pretty crappy and the dailer is once again nr 1 on partial wake.

What are your settings for gestures ?

Is "Incoming Call/Mute" turned on ?

I read somewhere here, and on XDA, that it might be the cause.

Guest Trym Hansen
Posted
Although I wouldn't characterise it as specialised, large Exchange databases benefit appreciably from this mod in day to day use. I also find a small but perceptible benefit in managing large music libraries (> 16GB so perhaps specialised). So I think that there some valid use cases that are more common than you elude to.

Sure, I'll admit to that, although I honestly haven't seen any such improvement myself. I think this is a case of "Unless you know you need it, you don't." I for one am very happy that the option now is deselected by default.

I'm a bit miffed you called my explanation "technical" though, it was designed to be anything but.... ;-)

::Trym

Guest wc326
Posted

i just want to ask , if using the 64 ram hack, which reduces gpu ram in half. Would you think that it will affect Browser performance when playing flash video etc with gpu ram reduce in half???

Guest Paul
Posted

Sorry, due to some complications (it's quite a big undertaking) the Norwegian fix won't be online until tomorrow.

P

Guest Paul
Posted

Looking forward to hearing whether people have noticed a real world battery life improvement in Fr16b4!

P

Guest wc326
Posted
Looking forward to hearing whether people have noticed a real world battery life improvement in Fr16b4!

P

about the same when using the phone. Not too sure about idle-ing the device. but i am going to sleep now. i will report back

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.