Related
This is a new thread with the same goal as my previous performance thread ' Turbo Speed X1 ', to tweak and speed up the performance of ROM 2.
I have a silver X1i with a 16gb SanDisk Micro SD ( Class 2 ), and I have just upgraded to ROM2 through the official update facility provided by Sony Ericsson, on the UK o2 network.
First impressions of ROM 2 are very positive, subjectively speaking. However I am going to be using Benchmarks to test and demonstrate any quantitative improvements. I am going to be using Spb Benchmark, widely regarded and well respected, avaliable free from the Spb Website.
http://www.spbsoftwarehouse.com/pocketpc-software/benchmark/
I will also include the results of SKTools5, we are all aware that results can fluctuate from run to run, but most people have this tool and it is quick to run, and can measure Memory Card Read and write speeds.
Tweak 1 - Cache Settings
These are the defualt settings that come with ROM 2, they should be the same for everyone who has upgraded, so we all start from the same level. They are captured and changed using Advanced Configeration Tools, posted below.
View attachment 175679
At first sight these settings are very similar to the defualt settings that came with ROM 1. So I changed them to settings that I found worked well with ROM1, they are as follows.
View attachment 175678.
Here are the defualt cache settings and new cache settings I have tested side by side for easy reference.
View attachment 175682
SPB Benchmark Results
First the results with Spb Benchmark, defualt on the left, new settings on the right. Green indicates faster results, red indicates slower results.
View attachment 175676
Observations from Spb
1) The majority of the tests showed a speed improvement with the New Settings.
2) Test 4 shows a 20% increase in speed, and Test 6 showed a 9% increase in speed, in my opinion both results are outside natural variation.
3) The two results that were marginally slower for the new settings were less than 3% slower which I would consider to be within natural variation.
Conclusions from Spb
The results indicate a speed improvement with the new settings, a 20% increase is significant.
SKTools Benchmark Results
View attachment 175677
Observations
There is significantly more variation with SKTools, the one result which stands out is SD Read Speed which shows consistantly up to 3 X Faster, with the New Cache settings.
Conclusions
A result of 3 X faster consistantly, run after run, cannot be explained away by natural variation. This is a very good positive result.
Overall
I am pleased with the first stage of tweaking ROM 2, it seems to respond in a similar if not slightly less dramatic way that ROM 1, but still increases of 20 % and upto 300% ( 3 X Faster ) for some things is still a good days work and well worth implimenting.
I welcome all contributions on this thread from Junior and Senior members alike, on tweaking, benchmarking the performance of ROM 2. This thread is not about me, or my personality, or what I had for breakfast. This thread is about improving the performance and experience of the X1, it is for all those who...
" feel the need...for speed. "
Player Slayer
Sometimes on this thread I may go off on a tangent into uncharted waters. I did it a few times on Turbo Speed X1 and got some good results, just by experimenting and playing around. Some Discoveries on ROM1 were :
Cluster Size increasing SD speed ( Cluster Buster ).
Ticking [Show All files] in File Explorer slowing performance down.
Having [autobacklight on] increasing performance.
Im not going to go over old ground, but I have gone off on a tangent this morning and discovered a new tweak and performance increase, which I will call ' Player Slayer '
I am going to set some simple ground rules for my contributions. First of all 90 % of the time, subjective tweaks and improvements are how my discoveries are made, how my phone feels, or by 'using the force'. This is all very well and good on a personal level but difficult to communicate on a thread like this, so I set a simple principle for my posts.
" If we cant measure it...we cant treasure it "
Also on Benchmarks I set the following guidelines to assess differences in results, before and after a tweak.
Less than 3% - Natural Variation - Insignificant.
Between 3 and 5 % - May prove interesting.
Between 5 and 10% - Definetely worth investigating.
Above 10 % - Probably a bonifide tweak or effect.
Above 15 % - Definetely a tweak.
Above 50 % - Break out the champagne.
Tweak 2 - ' Player Slayer '
On to this mornings foray into the unknown...the WM Twilight zone, inspired by the effect of [ Show all Files] in File explorer, I began to think about Media Player. Like File Explorer it is Microsoft and its functions are heavily embeded in the operating system.
On the Media Library screen, under menu, there is an option called ' Update Library ', see screen shots below. If you run this, Media Player performs an inventory of all the files on your X1 and your memory card and adds any media files to the Library.
View attachment 175822
If it finds files on your memory card it adds some system folders and files to your memory card, see below. Visible only if you Click [Show All Files] in file explorer.
View attachment 175821
The WMDRM folder is most interesting, no one knows what it is, and the file inside it is called ' 438F6A10A8D......'
To test the effect of the performing the inventory and the addition of the system files to memory card I did an experiment.
Procedure
1) I took the stock 4GB SanDisk memory card and formated it, using Storage Tools, so it was completely blank and wiped clean, I then ran the Spb Bench and the SkTools bench to get some defualt results.
2) I then went to Media Player and performed the 'Update Libarary' inventory.
3) I then ran the benchmarks again
Results from Spb
View attachment 175830
Green indicates faster, red indicates slower. On Spb bench the lower the value the faster the result, and only results that differ more than 5% have been highlighted.
Observations
Test 4 showed an 18% increase in speed, which by my own rule of thumb I consider to be very significant.
Results from SKTools
View attachment 175829
Observations
Again Green faster, red slower. On SKTools, the higher the values the faster the performance.
Main Storage Write Speed 8% faster.
Main Sorage Read Speed 11 % faster.
Conclusions
We have new tweak on our hands, ' Player Slayer '. If you dont use Media Player to play your Music and Video files you may never have done the Update Library Inventory, its not automatic, so its worth doing.
Explanations
I would theorise that performing a system wide file inventory allows the operating system to operate more efficiently, in laymans terms, once it knows whats there it can use it faster.
If members have a more scientific explanation for this effect please post them, I class this as classic case of WM eccentricity and part of what makes it such a fascinating operating system, like the wrinkles that add character to the face.
PS - Oh yeh and if you discover a new tweak, above 10%, you have have to give it a catchy ryhming name , and remember...
" A glass of Champaign a day...keeps the iphone at bay. "
Hi,
CTCNetwork said:
Hi,
Since updating the phone with the SE online updater this phone is running like a dog...
Aside from GPS problems it is s-l-o-w..
Two benchmarks done below:
Running on fairly normal settings but after an "Otimise":
Integer;244.4274;Moves/25 usec
Floating point;7.223;MWIPS
RAM access;1442;Speed index
Draw bitmaps;733;Speed index
Main storage (write);2004.57;KB/sec
Main storage (read);6606.45;KB/sec
Storage Card (write); 522.72;KB/sec
Storage Card (read);6206.06;KB/sec
File List;1328;Items/s
FL: Storage Card;4332;Items/s
SKTools loading;2672;ms
Optimised with the Schaps tool as well:
Integer;315.0765;Moves/25 usec
Floating point;7.055;MWIPS
RAM access;1426;Speed index
Draw bitmaps;808;Speed index
Main storage (write);2107.00;KB/sec
Main storage (read);6965.99;KB/sec
Storage Card (write); 592.36;KB/sec
Storage Card (read);6206.06;KB/sec
File List;1451;Items/s
FL: Storage Card;5185;Items/s
SKTools loading;5127;ms
Click to expand...
Click to collapse
In both instances the SD card speed up has been installed (to phone memory).
Nothing short of bad. Maybe I have a dud...?
Des. . .
Click to expand...
Click to collapse
Perhaps I should have been posting here!
What version of SPB tools do you have/use?
Des. . .
I used SKTools5 posted below, but I trust Spb Bench more results wise, but like ya said how your phone feels at the end of the day is what matters.
If you've updated to ROM 2 through Sony, did you remeber to format your Memory card as well, becuase in the post above, I described how WM places hidden system files on your X1. These system files, including Programs Folder are all designed for ROM 1, and if your running ROM 2 some of the programs could get confused.
My advice to back up on your PC all your personal data, music, films, software cab files etc from your memory card onto your PC and do a format of the memory card with the following Storage Tools. Under Fomat, click back-up FAT and choose 64 kb Cluster size which is the fastest.
Better still if you have time, do a hard reset, format your memory card and build your phone up again from scratch. Everyime you install some software , play with your phone a bit to see if it has any adverse affects. You should be able to find the offending program.
Do this then post back and tell how it feels, or show some results.
Hi,
Might just do a complete reset and take it from there.
I did format the card - on the PC but copied all the files from it and back to it after the format!
Will let you know how it goes.... Ta..
Des. . .
CTC Network - I was curious that you tried the SKTools Optimize Tweak and the tnyynt Tune up tweak on ROM 2 with no effect, so I tried them self. These are two tweaks which worked well with ROM 1, but like you , from the results I have benchmarked they show no significant performance increase.
Optimise Tweak using SKTools.
Here are the Spb results, before Optimise on the left, and after Optimise on the right.
View attachment 176431
Here are SKTools results, again before Optimise on the left, and after Optimise on the right.
View attachment 176432
I also tested the tnyynt Tune-up cab which you mentioned also.
tnyynt SD tune up tweak
Here are the Spb results, before on the left, after on the right.
View attachment 176434
Here are the SKTools results, before on the left, after on the right.
View attachment 176433
Conclusions as you can see, judging just on these two benchmarks alone, like you I found both the Optimize tweak and the SD tune up have no discernable benefit for ROM 2, and like you I am now doing a hard reset to build my phone up again from scratch.
The only two tweaks for ROM 2 that work so far, in my opinion, are to change cache settings as described earlier, and the new Player Slayer, described earlier.
Oh well, some days you eat honey, some days you eat straw.
Personal Comment
I have to say I am pleased with ROM 2, having just done a hard reset, and applied the two tweaks on this thread I am struggling to find anything worng with ROM 2, unlike ROM 1 I haven't found any areas where it is slow and lagging. The fact that some tweaks are not working like they did for ROM 1 is a good sign. If my X1 had performed like this when I first took it out of the box, I dont think I ever would have started Turbo Speed X1 thread. They just doesnt seem to be much slack in the system to improve, but I will keep looking just in case. In comparisons it is unfair to compare the X1 with other phones, but we can compare ROM 1 with ROM 2 and ROM 2 seems to be much better all round.
If any members are having performance issues and problems with ROM 2 please post them, becuase to be honest I dont have any problems with it. Good job Sony
Hi,
I have the SK file dumped on the phone so will post that later, however, what I did notice when checking through all the SK results on the benchmark was that the memory read speeds were near abysmal compared to the stock results that were listed.
I also notice that I seem to be using a larger chunk of memory with task manager regularly reporting 32% to 36% or memory in use. That is about 3% higher than I noticed before on the ROM one.
So perhaps SE have sacrificed some performance for either battery life or stability?
My main concern, GPS and using TT7, does appear to have passed as I nearly always get a fix within 20 seconds.
TT7 doesn't run as smoothly as it used to though and there appears to be a noticeable lag in where I am compared to where TT7 thinks I am.
Or I'm driving to fast!!
Will be watch ing this topic with interest.
Des. . .
I see you have a new thread.
I posted in the older one my benchmark results using this tool.
it is fast and has a compare with other devices function, showing a chart. neat!
this normally is shareware, but you can grab a legal license code here:
http://teksoftco.com/forum/viewtopic.php?t=2011
Hope this helps
G0.
Quote from Groundzer0 on Turbo Speed X1......." Hi Mark A Cilenti,
funny you ask me that since I got the program based on your recommandation in this thread
http://forum.xda-developers.com/show...&postcount=337
The program is Speedbooster, and you said it made your device faster.
The download is the link you posted previously:
http://www.teksoftco.com/index.php?section=speedbooster
The only thing I don't understand is that you said you've changed the priorities of several exe files, but on their website they recommand using only 1-2 boosted tasks at a time:
http://www.teksoftco.com/index.php?s...ster#practices
Maybe the difference is that your tasks are not all running at a time.
Anyway, this is a newer version, I'm using it after I read your posts here, and I can say that makes my GPS software go WOWW!! So I also recommand it.
And the good thing is that they have some weird contest on their forums, and are giving away free licenses (I guess it's some kind of promotion), check this too:
http://teksoftco.com/forum/viewtopic.php?t=2011
You could post this to your first page, since it seems a good tool and does speed up considerably. "
____________________________________________________________________________________
Groundzer0 - Brilliant I am so pleased you decided to post Speedbooster 2, I was playing with the older version the other day I had no idea a new version was out, Iv bought a license and here is my first Benchmark with nothing boosted, just the tweaks posted here on Turbo Speed Rom 2.
View attachment 177134
( Current High Score 6.45 )
The benchmark is also brilliant, clear, easy, quick and an overall score, this is the best race track weve ever had.
My Score = 6.45
Groundzer0 im sure you can do better than 6.0 , have you applied the 2 tweaks posted above ?
I will keep a current highscore with the name of any member who posts results on the thread title.
Come on lads, lets see what youve got under the hood
" First one to hit 7... is in X1 heaven "
Congrats on that!! 6.45 is huge
This guy here only got 6.00 on his xperia:
http://teksoftco.com/forum/viewtopic.php?t=2011#4703
I'm about to try your other tweaks as well. Thanks for this - you rock!
Hi,
Well, I am surprised. With only a few tweaks set (as defined by you, Mark) and having completed my re-install (including a reinstall of the re-install of TT7!) I managed the following results as attached...
Is this good??
Score: 6.38
CPU: 7.79
RAM: 7.11
Storage: 5.76
Video: 4.85
Des. . .
Good result, its about the same as mine, if your repeat the benchmark and disable all today Screen Plug-ins and turn phone and wifi off, you should get 6.45, although apart from once I have nt managed to get it again. I am now going to use SpeedBoost 2 to boost system processes, ( filesys, cprog, device, gwes, shell32, services etc ) found under Processes in SpeedBoost 2, I hope to get close to 7.
By the way whats TT7, is it a tweak ?
And what are your cache settings ?
Hi,
Mark A Cilenti said:
By the way whats TT7, is it a tweak ?
And what are your cache settings ?
Click to expand...
Click to collapse
TT7 = TomTom 7
And cache setting, I believe were the same as you detailed above..
Something that maybe worth playing about with, I think.
Ultimately though, tweaking one thing or another to benefit one performance measure will lose out on another.
Given my phone seems to be performing pretty much similarly to yours I can surmise that the phone is Ok and performing as should be.
Maybe it will be time to try a different ROM one day!
Will see what other settings get and what results are achieved.
I know that using SE panel 1 gives a hit on memory, but perhaps not on performance. Might be different for the other panels?
Des. . .
Devil may Cry - 6.66 Points!
Ethermind, care to share how you achieved such excellent results? I can only get around 6.30, but not on a freshly installed rom.
it is on not very fresh, but cleaned up ( down to 100mb ) ROM
i just use adv config tool
> perfomance
cache - on
cache of fs - 8 mb
filter of fs cache - 32768 sect
cache of fonts - 64 kb
also i used tyyntSD, but not sure is active : )
BTW first time it was just 6.50, then 6.66 and then 6.48
6.66 is the best : )
i think random component is present : )
Ethermind that looks like an excellent result, your sktools results are interesting, they are not ROM1 or ROM2, i think you are runnning a custom ROM, and its a hot rod. Your name goes on the scoreboard anyway, even if you have a rear difuser ha ha, respect.
i just deleted from ROM2 some apps (windows live, getting started, some panels), replace x1 calculator on htc calculator, replace picas of dialer etc.
so i think it can not affect prefomance : )
Ethermind I agree with what you said, if we continue with the car analogy, a stripped out car, shedding weight will increase performance. I only install whats absolutely necesary and when im ' racing ' I have a stripped out Today Screen. Apps and plugins are like air con, sat nav, stereo and electric windows, they will weigh you down when racing.
This is my stripped down Today screen for race mode.
View attachment 178100
A Clock, bluetooth, wifi and phone toggle with programs and settings at the moment, at the end of the day this is all you really need. HomeSCreen ++ does all that. I wonder if I can shed some more weight
if so, then we must awaiting better result from lite rom user's : )
Hi,
I have noticed that my Nexus' performance starts to drop after some hours on: going from one home screen to the other becomes quite choppy, and so do the animations of opening an application.
Have you guys noticed that too, or is it just me?
It was like this for me until I bought Advanced Task Manager. I have it auto end applications that I don't need to run all the time. It runs much better now.
The issue is RAM. The kernel that shipped with the Nexus One doesn't support the full 512MB of RAM. However, CyanogenMod 5.0-beta4 does and the difference in speed is amazing. With 26 apps running I have 167MB free atm.
But like stickerbob said, you should have Advanced Task Manager at the least.
Deathwish238 said:
The issue is RAM. The kernel that shipped with the Nexus One doesn't support the full 512MB of RAM. However, CyanogenMod 5.0-beta4 does and the difference in speed is amazing. With 26 apps running I have 167MB free atm.
Click to expand...
Click to collapse
I don't get it. Isn't Android supposed to kill unused apps when it's running out of RAM?
frandavid100 said:
I don't get it. Isn't Android supposed to kill unused apps when it's running out of RAM?
Click to expand...
Click to collapse
Yep but some people just don't get that, ah well...
efeltee said:
Yep but some people just don't get that, ah well...
Click to expand...
Click to collapse
Well, that doesn't really explain the performance drops. Does the phone run out of RAM, or not? It seems to be snappy again after a reboot, so there must be something.
frandavid100 said:
I don't get it. Isn't Android supposed to kill unused apps when it's running out of RAM?
Click to expand...
Click to collapse
That is what I have read, but it did not work for me. I downloaded the free version of advanced task man to troubleshoot the problem and found that most of my apps were still running in the background even when my ram was down to 10-20mb. That is about when the phone would start acting up on me. When I ended the tasks the phone would act normal again. So I just broke down and bought the app for $.99. If you do this make sure you exclude some system apps, if you don't your phone could freeze while it is trying to restart them.
10-20mb free is normal operation. This is how the OS is designed to operate, linux and even windows7 now also operate in this fashion (show very little 'free' memory). there is no performance problem with low free memory, purely a misconception on modern memory managment. Whats going on is that you have a buggy application, which is why 'killing' apps looks to be resolving your issue. You're only resolving the symptom, not the problem.
I never kill apps and have had weeks of uptime without any slow down. This gets rehashed over and over again by people claiming task killers help performance. The reality is they do nothing for performance, only nice to have around for that great once and a while an app runs away from you, or in troubleshooting if you have a poorly written app. It should not be anyones habit to do a kill all on a regular basis, if it were the OS would do this automatically.
btw, compcache has been known to cause this slowdown over time issue, it has since been removed from most of the popular custom baked rom's.
frandavid100 said:
I don't get it. Isn't Android supposed to kill unused apps when it's running out of RAM?
Click to expand...
Click to collapse
Yes it does...
bofslime said:
10-20mb free is normal operation. This is how the OS is designed to operate, linux and even windows7 now also operate in this fashion (show very little 'free' memory). there is no performance problem with low free memory, purely a misconception on modern memory managment. Whats going on is that you have a buggy application, which is why 'killing' apps looks to be resolving your issue. You're only resolving the symptom, not the problem.
I never kill apps and have had weeks of uptime without any slow down. This gets rehashed over and over again by people claiming task killers help performance. The reality is they do nothing for performance, only nice to have around for that great once and a while an app runs away from you, or in troubleshooting if you have a poorly written app. It should not be anyones habit to do a kill all on a regular basis, if it were the OS would do this automatically.
btw, compcache has been known to cause this slowdown over time issue, it has since been removed from most of the popular custom baked rom's.
Click to expand...
Click to collapse
Well then there must be many buggy applications. I had to rely on Advanced Task Manager to keep my G1 running acceptably fast. The N1 slows down without its full RAM available so I needed to use Advanced Task Manager then too.
If the RAM is not the issue, why does having the extra 200 MB available make the phone run much smoother with 20+ apps running?
frandavid100 said:
I don't get it. Isn't Android supposed to kill unused apps when it's running out of RAM?
Click to expand...
Click to collapse
well technically no, it reallocates what is being used and frees up memory for programs currently running but non the less the OS manages itself
personally i close apps that i do not have going with the task manager. i seem to notice a performance difference if i do it manually, it takes 2-3 extra taps for peace of mind rather than relying on the OS to figure it out for me...
Deathwish238 said:
The issue is RAM. The kernel that shipped with the Nexus One doesn't support the full 512MB of RAM. However, CyanogenMod 5.0-beta4 does and the difference in speed is amazing. With 26 apps running I have 167MB free atm.
But like stickerbob said, you should have Advanced Task Manager at the least.
Click to expand...
Click to collapse
The speed benefits of CM's ROM isn't due to the HIGHMEM supporting kernel, but rather other tweeks he's done with his build. Extra ram is nice, but there is certainly no limitation with the 213 or so userspace memory that is available now. Android itself does not even use this memory, it has its own reserved memory space, userspace memory is only for applications to be loaded in. And there is speed for keeping as much of your applications loaded in memory as possible.
swetland said:
Roughly 220MB is available to userspace in the shipping build (ERD79).
Quite a lot of memory is dedicated to the radio firmware (41MB), dsp firmware (32MB), display surfaces (32MB), gpu (3MB), camera (8MB), a/v buffers (41MB), and dsp buffers. Much of this needs to be set aside for these specific tasks due to hardware requirements of very large physically contiguous buffers which can be difficult or impossible to obtain after boot once the physical memory space gets fragmented.
The big limitation though is that the Linux kernel needs to do a 1:1 physical:virtual map of general purpose memory used by the kernel and userspace (which excludes the special purpose stuff described above). This eats into the available kernel virtual address space, which is also needed for cross process shared memory used by the binder, etc. Run out of virtual memory and things get unhappy.
In 2.6.32, HIGHMEM support for ARM will allow us to avoid this requirement for a 1:1 mapping which will allow us to increase memory available to userspace without running the system out of virtual memory adddress space.
Click to expand...
Click to collapse
The speed difference I'm talking about is what I experienced when running CM beta3 and CM beta3 w/ highmem. The difference was huge. I assumed the change was mainly attributed to the double RAM available.
Even now with the full RAM available, things run faster when I end the other apps running. It's not necessary, but the difference is there.
It would be nice to be able to pinpoint which apps caused slow downs.
The best way I've seen this put I found in a thread where someone wanted to disable apps from auto-starting entirely. I saved it, because I though it was very elegant way to explain androids mem management.
equid0x said:
I just wanted to chime in here about the whole apps on startup thing....
Android has the concept of services which are programs that typically have a frontend piece, like a GUI for IM that you would normally use, that only runs when you are using it, and a background piece, the service, which is constantly running to keep you connected to your IM servers. This will account for some portion of the things you see running on startup, depending on how many apps you have installed, and whether or not they were written to run as a service.
There are also some, usually older, android programs that existed before "services" were really used.. that basically use triggers to keep reloading themselves. These programs are less efficient, and probably should be re-written to use the official service method of operation, caveat emptor.
Android also makes several modifications to the stock process handling that comes with any Linux kernel, which is already radically different from what most would be used to seeing on Windows as it is. Android attempts to keep commonly used applications running(loaded into memory), but in a sleeping state (using no cpu), so that they may be quickly resumed on request. Android also contains some agressive modifications to the behavior of the OOM(out of memory) task killer in Linux, that seem to cause it to keep applications running until nearly all memory is consumed, killing apps it deems unnecessary only when absolutely necessary. However, Android also supports a methodology of saving the running state of a program, so that if it is killed due to an OOM condition, it may be restarted with relevant data restored, to give the appearance of never having been killed at all.
This functionality is not all to alien to Linux as a platform in general, though Android has many modifications which tend to favor aggressive app management in memory, and less so filesystem cache. This was likely a design choice made to suit the low-speed/low memory platforms Android targets.
Click to expand...
Click to collapse
Good read.
So then given that...only services running should slow down the phone and not the background apps running.
However, this doesn't really answer the OP's question. If it's not a memory issue...what's causing his slowdowns?
Could be too many widgets on the home screen, I don't run that many but its possible that while in an app for a while, and switching back to home the OS may have to kill a whole bunch of apps to allow it to reload all the widgets on the home screen.
I tested this, and loaded the crap out of my home screens with widgets, and then launched a game. When I exited the game there was a good 500ms - 800ms delay in my homescreens from displaying anything other than the background. However, after it loaded, scrolling between screens looks smooth. The new kernel with highmem support can help this, but I would suspect some crazy widget filled homescreen with a 3rd party live wallpaper (star's configured with too many stars) and all of that combined could be an issue even still. Apple combats this by allowing only one app at a time, they know people will go overboard if allowed.
Well, that doesn't really explain the performance drops. Does the phone run out of RAM, or not? It seems to be snappy again after a reboot, so there must be something.
Click to expand...
Click to collapse
There's probably no easy answer to this question. There could be IO contention, a runaway process, high CPU usage, a memory leak, shoddy code in some app, etc etc... One would really have to take a look at the whole state of the system at the time the problem is happening to be able to ascertain what is causing the slowdown.
The phenomenon is in no way unique to Android. I'm sure nearly everyone is familiar with the common complaint "my computer is running slow". The reasons that can happen on a common PC are the very same reasons that can be happening here, and unfortunately there are many of those reasons. While in many cases, throwing memory at the issue may appear to solve the problem temporarily, it often is not a permanent fix.
The amount of userspace memory available really amounts to 1 thing and 1 thing only -> the total number of running processes that we can keep totally in memory at any given time. On stock android, slowdown due to an OOM condition should be minimal, since stock android doesn't swap. Discounting any other bottlenecks, there is a practical limit to the number of programs once would be able to run in the memory space that is available. Realistically speaking, android programs tend to be fairly small, so you'd really have to be running a lot of them to exhaust this space. It is far more likely one or 2 poorly written programs are hogging huge amounts of memory (and probably other resources), which is causing constant killing and restarting of other apps you are trying to run concurrently. You end up with contention on the slow flash, resulting in poor performance.
You can't even really compare the Nexus One to the G1 in this regard, because the G1 truly is terribly deprived of memory. Though, the argument in both cases could really be made that you are attempting to run the hardware beyond its design specifications...
Its been my experience that the culprit is usually one or 2 specific programs. Sometimes the best, although inconvenient, way to figure out which programs these are, is to keep watch of your usage habits, and if you suspect something is the problem, uninstall it, and see if the issue persists. Its time consuming but there really isn't any better way to figure it out without using all kinds of tools that android doesn't really provide convenient access to. There are a few apps on the market that help with this but I am not sure what they are called offhand.
Programs that were identified as sources of slowdown for me have been:
Weatherbug
The Weather Channel
Calorie Counter
Locale
SMS Popup
10000
USA Today
National Geographic Wallpapers
CNN News Widget
Streamfurious
Nav4All
Waze
Just about every app with Admob Ads
And this is really just what I can think off offhand... there are more...
equid0x said:
There's probably no easy answer to this question. There could be IO contention, a runaway process, high CPU usage, a memory leak, shoddy code in some app, etc etc... One would really have to take a look at the whole state of the system at the time the problem is happening to be able to ascertain what is causing the slowdown.
The phenomenon is in no way unique to Android. I'm sure nearly everyone is familiar with the common complaint "my computer is running slow". The reasons that can happen on a common PC are the very same reasons that can be happening here, and unfortunately there are many of those reasons. While in many cases, throwing memory at the issue may appear to solve the problem temporarily, it often is not a permanent fix.
The amount of userspace memory available really amounts to 1 thing and 1 thing only -> the total number of running processes that we can keep totally in memory at any given time. On stock android, slowdown due to an OOM condition should be minimal, since stock android doesn't swap. Discounting any other bottlenecks, there is a practical limit to the number of programs once would be able to run in the memory space that is available. Realistically speaking, android programs tend to be fairly small, so you'd really have to be running a lot of them to exhaust this space. It is far more likely one or 2 poorly written programs are hogging huge amounts of memory (and probably other resources), which is causing constant killing and restarting of other apps you are trying to run concurrently. You end up with contention on the slow flash, resulting in poor performance.
You can't even really compare the Nexus One to the G1 in this regard, because the G1 truly is terribly deprived of memory. Though, the argument in both cases could really be made that you are attempting to run the hardware beyond its design specifications...
Its been my experience that the culprit is usually one or 2 specific programs. Sometimes the best, although inconvenient, way to figure out which programs these are, is to keep watch of your usage habits, and if you suspect something is the problem, uninstall it, and see if the issue persists. Its time consuming but there really isn't any better way to figure it out without using all kinds of tools that android doesn't really provide convenient access to. There are a few apps on the market that help with this but I am not sure what they are called offhand.
Programs that were identified as sources of slowdown for me have been:
Weatherbug
The Weather Channel
Calorie Counter
Locale
SMS Popup
10000
USA Today
National Geographic Wallpapers
CNN News Widget
Streamfurious
Nav4All
Waze
Just about every app with Admob Ads
And this is really just what I can think off offhand... there are more...
Click to expand...
Click to collapse
I'm banking on it being an issue with an app that the OP has installed as well...not the phone or Android. I have only a handful of tried and true apps, and haven't experienced a slowdown even after 150 hours without a reboot.
OP... start uninstalling apps a couple at a time and wait several hours in between to narrow down the problem app.
I can't speak for the OP, but when I was having that problem I had 5 widgets running on my home screen. The Google Search, Sports Tap, Power Control, Calendar, and The Small Weather Channel. Does this seem like too much? I hope not.
stickerbob said:
I can't speak for the OP, but when I was having that problem I had 5 widgets running on my home screen. The Google Search, Sports Tap, Power Control, Calendar, and The Small Weather Channel. Does this seem like too much? I hope not.
Click to expand...
Click to collapse
It's not just widgets that you should be thinking about... any app you've installed can throw something off.
stickerbob said:
I can't speak for the OP, but when I was having that problem I had 5 widgets running on my home screen. The Google Search, Sports Tap, Power Control, Calendar, and The Small Weather Channel. Does this seem like too much? I hope not.
Click to expand...
Click to collapse
I removed the weather & news widget and the phone seems much faster now. I'll keep it like that for a day, see if it stays fast.
Thought I would record my troubles with a game render loop and a logic engine given a particular bug has swallowed up about a week of my time. I am posting it incase anyone else happens to have the same problem/symptomns.
It originated when I wrote the LogicEngine which has an ArrayList of GameObjects and iterates through them deleting them as nessesary depending on the results of thier processStep.
The render thread would occasionally crash when something was deleted from the array while the list was being drawn but this happened quite rarely. No problem I thought, I'll just catch the out of bounds exception and it will get displayed on the next frame however many milliseconds later.
This all went well for 3 months of coding till I got to programming terrain where about 300 blocks were all displayed gradually scrolling down the screen. The blocks would flash intermittently but in sections not all at once.
At first I thought it was too many blocks for the LogicEngines collision detection so I doubled the size of the blocks. Then I thought it might be overhead allocating memory for the blocks and preloaded them in the constructor. Eventually in despair I disabled the deletion of blocks once they went offscreen and noticed the flashing stopped. This was the point I realised what was happening: The LogicEngine would delete a row of blocks because they went offscreen and the Renderer would be half way through drawing and instead of crashing it would just skip x blocks wherever it was in the for loop at the time that the LogicEngine removed them.
Wow I feel stupid, especially because of the lazy Exception catching solution I originally implemented which masked the problem for so long.
Code:
GameRender.java
//draw obstacles
theLogicEngine.objectsObstaclesLock.writeLock().lock();
for(int i=0 ; i<theLogicEngine.objectsObstacles.size();i++)
{
drawObject(theLogicEngine.objectsObstacles.get(i));
}
theLogicEngine.objectsObstaclesLock.writeLock().unlock();
LogicEngine.java
for(int i=0;i<objectsObstacles.size();i++)
if(objectsObstacles.get(i).processStep(this)) //we are to delete this object
{
objectsObstaclesLock.writeLock().lock();
//remove self if necessary
//move object returned true so delete object
GameObject toDelete = objectsObstacles.get(i);
objectsObstacles.remove(i);
toDelete.dispose();
i--;
objectsObstaclesLock.writeLock().unlock();
}
TLDR: If you have an ArrayList that can be edited by one thread, make sure you lock it rather than just catching the ArrayOutOfBoundsException
Glad you figured it out
I am still impressed that you can write Android games using these techniques. Is your game low-res or is Dalvik that powerful?
I mean, you are using Java, which is one thing, but then you use ArrayList and you delete objects as you go. I take this to mean that you do not recycle them in a pool.
Am I correct?
cyansmoker said:
Glad you figured it out
I am still impressed that you can write Android games using these techniques. Is your game low-res or is Dalvik that powerful?
I mean, you are using Java, which is one thing, but then you use ArrayList and you delete objects as you go. I take this to mean that you do not recycle them in a pool.
Am I correct?
Click to expand...
Click to collapse
ArrayList is self managing.
All of Java's garbage collection is done automatically. As a Java dev u can call System.gc but this only suggest the system attempt gc.
Dalvik is pretty good, but anything extensive I would go native...
Sent from my Galaxy Nexus using Tapatalk
jug6ernaut said:
ArrayList is self managing.
Click to expand...
Click to collapse
Right. But then there is the memory consumption issue. That's why I typically do things as described in this blog entry.
jug6ernaut said:
All of Java's garbage collection is done automatically. As a Java dev u can call System.gc but this only suggest the system attempt gc.
Click to expand...
Click to collapse
Although in System.gc()'s defense I've always observed that it was run immediately in Sun's ref. implementation. Not sure about Dalvik.
But overall I agree with your conclusion.
cyansmoker said:
I am still impressed that you can write Android games using these techniques. Is your game low-res or is Dalvik that powerful?
Click to expand...
Click to collapse
So far I have not been having any performance issues. The ArrayLists contain GameObjects which are quite lightweight memory wise as they do not contain Textures.
Textures are maintained in separate dictionary with a string key.
I did try recycling GameObjects in one location where I was spawning / destroying a lot but it didn't really seem to impact performance much.
I think my biggest area for optimisation at the moment is in collision direction. Currently there are about 5 different ArrayLists (Obstacles, Enemies, Players, Player Bullets, Enemy Bullets etc) only those that interact are tested for collision (Vector2d distance < objects collision radius). I think theres probably opportunity to split it further into quads.
I've yet to build in proper optimisation checking but it plays fine in 320x480 with ~100 enemies on screen and 4 player ships with maybe 20 bullets on screen at once with a turnover of 5/10 GameObjects a second. Even with this number though Texture memory usage is low with most enemies between 16x16 and 48x48.
I think libgdx and the behaviours library I use are pretty optimised.
I chanced upon an app that could enable android users the ability to true multitask. Android is designed to cleverly close apps in the background that it deems unimportant. This feat is brought to fruitation through the assigning of minfree values. The higher the minfree value, the more seceptible the app is in being axed to conserve ram and computing space which inturn conserve battery.
With this in mind, theoretically, if we assign an app with a minfree value of 0, the apps will not be killed even when kingdom come. Pardon my attempt at humour if you aren't chuckling.
Now to the crux of this post. There is an inherent difficulty to assign minfree values and not everyone is a coder. Luckily there is an app on the market which let users assign minfree values and better yet, filters the apps into hidden apps and stuff. Simply download this free application from the market:
https://play.google.com/store/apps/...t=W251bGwsMSwxLDEsImNvbS5ycy5hdXRva2lsbGVyIl0.
Go to settings, enable advanced mode to get access to the first three values. One simply inputs "0,0,0,0,0,0". And voila, theoretically all hidden/background apps will not be killed and true multitasking is achieved.
A quick test of some programs that are designed to close after home button is pressed does not close now. Am happy to report that this trick does not close any background app. Only downside is user has to manually close the apps, which for me is more than ok. Hope this helps!!
[Update] I have changed all fields to 0. So technically what I am telling the GSIII is "do not have coffee breaks,toilet breaks and oh, "I own your sorry ass".
Am excited to report that N.O.V.A. 3 still continued running after opening maps with GPS, XDA, Maps, Internet browser. All of which are running.
[Update 2] Edited the values to "0,0,1,1,1,1" as a failsafe in case all rams have been used up. E.g. NOVA3 and MC3 concurrently running due to carelessness. Will report any drastic behaviour or successfully implementation without much drawbacks.
Sent from my GT-I9300 using xda premium
I'm interested to know how this affects battery life.
jiggytom said:
I'm interested to know how this affects battery life.
Click to expand...
Click to collapse
I am pretty sure this will suck the bejesus out of the battery. : ) Plus we aren't using the software for its intended use.
I did the same
Interesting to try...
sebarkh said:
I did the same
Interesting to try...
Click to expand...
Click to collapse
If in the event u have reached a satisfactory value do share! I was inspired by the "backgrounder" program of jailbroken IOS devices. It does the same thing except our way is different. From my Iphone days I have fetishes of true multi tasking. : )
Sent from my GT-I9300 using xda premium
The Linux/Android kernel WILL run OOM-Killer (Out-of-memory) with SIGKILL (removes the process from RAM and CPU without letting it any chance to save data or report) when the memory is full and it cannot continue operation otherwise.
Dalvik _should_ work around a full memory but by disabling this feature it won't so you might experience some data loss.
Consequently it is necessary to have a sufficiently large Swap-Partition on your SDcard to allow the kernel to get more memory whenever needed. It won't be fast when it hits the limit but at least it still works.
d4fseeker said:
The Linux/Android kernel WILL run OOM-Killer (Out-of-memory) with SIGKILL (removes the process from RAM and CPU without letting it any chance to save data or report) when the memory is full and it cannot continue operation otherwise.
Dalvik _should_ work around a full memory but by disabling this feature it won't so you might experience some data loss.
Consequently it is necessary to have a sufficiently large Swap-Partition on your SDcard to allow the kernel to get more memory whenever needed. It won't be fast when it hits the limit but at least it still works.
Click to expand...
Click to collapse
Well on top of that, the Minfree was programmed so that the CPU doesn't have to overwork and so it can run at lower frequencies.
Interesting app, but I'm going to leave the programming to the experts.
Plus prog is too much of a hassle for too little gains in this case. Hahaha.
I have to say that I miss the way the Palm Pre multitasked the best. I also like how pre handled contacts with multiple numbers/IM/google etc (something that ios6 is finally going to attempt to do). It would incorporate all of them into one message window using icons. If only some of that could be incorporated into Android!
Hello everyone, after a long day of research(googling) and tweaking with various things with this phone I think I may have stumbled upon a way to run our 5Xs in 32-bit mode. In the system folder lies a file called build.prop(Make a copy of this and place it somewhere safe), pull this file and edit these lines:
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.features=default
and change them to:
dalvik.vm.isa.arm64.features=lpae,div
dalvik.vm.isa.arm.features=lpae,div
after you're done editing push the build.prop file back to the system folder and apply these settings: Chmod 0644 (rw-r-r)
I personally have done this tweak and noticed that even when running heavy apps such as Chrome with multiple tabs open and YouTube while playing 1080p videos in split screen mode that the system always has 400 - 600mb of ram available for use. I would love for a developer to please pipe in and explain what exactly these edits are doing. From my understanding these edits are telling the processor to execute code in 32-bit(exclusively?) instead of the default 64-bit and 32-bit mode. If anyone else is open to try this please give your experiences with this tweak.
Interesting, gonna try this... I guess there's not even a point in having a 64 bit processor with only 2GB of RAM
edit: It definitely feels kinda different... I managed to get Facebook, Messenger, Snapchat, Instagram, Google Photos, YuBrowser and YouTube opened at same time with 281MB to spare.
If anyone is interested to no about Linux.arm lpae here's some information that might be interesting...
Also this is very interesting..
64-bit operation enables applications to use a larger virtual address space. While the Large
Physical Address Extension (LPAE) extends the physical address space of a 32-bit
processor to 40-bit, it does not extend the virtual address space. This means that even with
LPAE, a single application is limited to a 32-bit (4GB) address space. This is because
some of this address space is reserved for the operating system.
• Software running on a 32-bit architecture might need to map some data in or out of
memory while executing. Having a larger address space, with 64-bit pointers, avoids this
problem. However, using 64-bit pointers does incur some cost. The same piece of code
typically uses more memory when running with 64-pointers than with 32-bit pointers.
Each pointer is stored in memory and requires eight bytes instead of four. This might
sound trivial, but can add up to a significant penalty. Furthermore, the increased usage of
memory space associated with a move to 64-bits can cause a drop in the number of
accesses that hit in the cache. This in turn can reduce performance.
The larger virtual address space also enables memory-mapping larger files. This is the
mapping of the file contents into the memory map of a thread. This can occur even though
the physical RAM might not be large enough to contain the whole file.
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
edoardotavecchio said:
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
Click to expand...
Click to collapse
To be honest I don't think that it's going to have any significant changes to battery life it's more of a way that the memory management is handled between 32bit &64bit process but I'm no expert..
dog121 said:
To be honest I don't think that it's going to have any significant changes to battery life it's more of a way that the memory management is handled between 32bit &64bit process but I'm no expert..
Click to expand...
Click to collapse
Yes I know but as an information techonology student and Android enthusiast I've found that everything could bring unexpected results lol so I'm Just asking to the OP for some testing
what about stability? apps like play services are made for 64bit devices, doesn't this mod cause stability problems?
edoardotavecchio said:
Yes I know but as an information techonology student and Android enthusiast I've found that everything could bring unexpected results lol so I'm Just asking to the OP for some testing
what about stability? apps like play services are made for 64bit devices, doesn't this mod cause stability problems?
Click to expand...
Click to collapse
Can't answer that .. Can say that it seems to be running with out any issue but I can't even say whether or not these two lines of code are actually taking affect ..After reading a considerable amount of information on lpae I seriously don't think that this is achieving any significant changes to the system management which Is kernel related as far I I know ..But like I said I'm no expert and could be totally wrong
I'm actually really curious as to what effects this could have, and if one could go further toward 32-bit based RAM management. I'm not currently rooted, so I can't modify my build.prop, but I certainly plan to try it soon. As the OP said, I'm wondering if a developer, or perhaps just someone more knowledgable could provide any input as to what this is really doing. Always exciting to find something new!
Should we wait and hope that someone sees this post or maybe PM some of the developers for this device asking for an opinion?
Appreciate the responses guys, I'm hoping that this thread will garner enough attention to get a developer in here and help us out a bit with this.
HesThatGuy said:
Hello everyone, after a long day of research(googling) and tweaking with various things with this phone I think I may have stumbled upon a way to run our 5Xs in 32-bit mode. In the system folder lies a file called build.prop(Make a copy of this and place it somewhere safe), pull this file and edit these lines:
dalvik.vm.isa.arm64.features=default
dalvik.vm.isa.arm.features=default
and change them to:
dalvik.vm.isa.arm64.features=lpae,div
dalvik.vm.isa.arm.features=lpae,div
after you're done editing push the build.prop file back to the system folder and apply these settings: Chmod 0644 (rw-r-r)
I personally have done this tweak and noticed that even when running heavy apps such as Chrome with multiple tabs open and YouTube while playing 1080p videos in split screen mode that the system always has 400 - 600mb of ram available for use. I would love for a developer to please pipe in and explain what exactly these edits are doing. From my understanding these edits are telling the processor to execute code in 32-bit(exclusively?) instead of the default 64-bit and 32-bit mode. If anyone else is open to try this please give your experiences with this tweak.
Click to expand...
Click to collapse
That will not make them run in "32-bit mode" what you can do when compiling is making certain memory calls 16 bit wide and that can actually increase performance in some cases.
I'd done that at compile time for some ROM's and kernels and it does work fairly well while not affecting performance or stability negatively.
LPAE is just a way for 32 bit OS's to acces memory above the 4GB limit, i don't know why you think that would do anything at all. It will literally do NOTHING for a 64 bit kernel based OS and it will have the opposite effect on a 32 bit Kernel OS that has support for LPAE.
Here's a writeup on LPAE http://elinux.org/images/6/6a/Elce11_marinas.pdf
It's a kernel enabled feature in 32 bit systems, if it's enabled it can be disabled in the build.prop but it cannot be enabled since it's enabled by default in 32 bit kernels.
The only thing a 32 bit mode would do is slow down memory access for a 64 bit kernel, it's silly and unimportant since 32 bit code will be run exactly the same except access to anything above the 4GB limit in memory.
---------- Post added at 06:54 AM ---------- Previous post was at 06:51 AM ----------
edoardotavecchio said:
Does this have any impact on battery? Obviously, just using less memory is good but I'm searching for more battery without sacrificing performances too much.
Click to expand...
Click to collapse
Since it is only applicable to 32 bit kernels it won't do anything and won't have any effect on anything what so ever. You can add a line that reads "make.my.phone.fastest=yes" and it will have the exact same effect.
@Nicktheprofessor My post is not directed specifically towards LPAE, it is focused on finding out what exactly these edits are telling the processor to do. The main command if anything is "div" which from my understanding is telling the processor to execute code with 32-bit instructions exclusively instead of the default of executing in 64-bit and falling back to 32-bit when necessary. Thank you for adding to the conversation though.
HesThatGuy said:
@Nicktheprofessor My post is not directed specifically towards LPAE, it is focused on finding out what exactly these edits are telling the processor to do. The main command if anything is "div" which from my understanding is telling the processor to execute code with 32-bit instructions exclusively instead of the default of executing in 64-bit and falling back to 32-bit when necessary. Thank you for adding to the conversation though.
Click to expand...
Click to collapse
OK, let's make sure this is very clear then.
The DIV bit cannot turn 64 bit compiled instructions into 32 bit instructions, it doesn't work that way, the DIV bit is a 64 bit specific instruction set.
Now if you have a 32 bit system with LPAE support you can set DIV to LPAE so that memory addressing can be made using 64 bit memory allocation.
If you have a 64 bit system running a 64 bit instruction set it's on no matter what you do, you need to use a 32 bit instruction set in the code itself to change that.
Here's a very simple explanation: https://www.tptp.cc/mirrors/siyobik.info/instruction/DIV.html
It shouldn't be too hard to rewrite the specific kernel additions and compile it in a 32 bit instruction set but you'd have to provide the LPAE layer to get it to communicate with the 64 bit layer.
What you'd end up with would be horridly slow though and i don't see the point in your endavour, do you even understand the concept of instruction sets?
@Nicktheprofessor Correct me if I'm wrong please. My basic understanding of instruction sets are that they tell the processor how to operate in general and how to execute code to run different software.
As for my endeavor, I'm looking into a way of reducing the system's memory usage as I don't feel that 2GB of RAM for a 64-bit Android system is truly enough. Thanks again though for providing info for me to learn about this stuff.
HesThatGuy said:
@Nicktheprofessor Correct me if I'm wrong please. My basic understanding of instruction sets are that they tell the processor how to operate in general and how to execute code to run different software.
As for my endeavor, I'm looking into a way of reducing the system's memory usage as I don't feel that 2GB of RAM for a 64-bit Android system is truly enough. Thanks again though for providing info for me to learn about this stuff.
Click to expand...
Click to collapse
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Nicktheprofessor said:
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Click to expand...
Click to collapse
Ahh I see now, I'm still learning all there is to know about how the Android ecosystem works and I appreciate the responses and info my dude. Addressing your ZRAM statement, I would like to find a way to run this phone without ZRAM and without sacrificing memory space as I notice frequently how slow it is for the phone to push & pull things in & out of swap especially when the swap space is nearly filled.
Nicktheprofessor said:
The point is that you can't run 64 bit native code as a 32 bit instruction set, it is 64 bit as is in source and in it's binary form, it cannot be executed using a 32 bit instruction set. To test this for yourself, try to run 64 bit code on a 32 bit system, it won't work and neither could you run the phone as a 32 bit system executing 64 bit code.
To actually reduce a memory footprint you'll need compilation flags, i suggest using a 16-bit addressing alternative (-mfpu=neon-fp16 -mfp16-format=alternative) instead.
I used to use that on another phone and it did actually help a bit.
2GB is plenty for 64bit though, especially since we're using ZRAM and 64 bit allocations will have higher compression values.
Click to expand...
Click to collapse
I dont understand, if you are using 16bit adress and 64bit words u dont get 2 GB ram..
2^16*64b/8b = 524,288 B of ram...
By the same calculation 28 bits would be enough for 2GB of ram with 64bit words.
If u lower the word size u need more adress space to adress the same memory, so i dont understand why 16bits?
Sent from my Nexus 5X using Tapatalk
InterrtuptoR said:
I dont understand, if you are using 16bit adress and 64bit words u dont get 2 GB ram..
2^16*64b/8b = 524,288 B of ram...
By the same calculation 28 bits would be enough for 2GB of ram with 64bit words.
If u lower the word size u need more adress space to adress the same memory, so i dont understand why 16bits?
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
It's known as half-precision floating point and it can improve performance in some cases and save cache space but you still have 64 bit code and 64 bit memory allocation.
You can't fix that without actually rewriting code.
---------- Post added at 03:32 AM ---------- Previous post was at 03:27 AM ----------
HesThatGuy said:
Ahh I see now, I'm still learning all there is to know about how the Android ecosystem works and I appreciate the responses and info my dude. Addressing your ZRAM statement, I would like to find a way to run this phone without ZRAM and without sacrificing memory space as I notice frequently how slow it is for the phone to push & pull things in & out of swap especially when the swap space is nearly filled.
Click to expand...
Click to collapse
Well you could just edit the init files and not have ZRAM at all but still support for it in the kernel, the phone will still work just fine but i sincerely doubt you will see much improvement.
Also the cache speeds are not slow in the least, i don't know where you get that from considering that decompression is done on the fly using the fastest algorithm possible and uses all available cpu's. I don't think you can improve on that much.
SWAP space on this phone is ZRAM, there is no physical memory put aside to do that job so...
However, unchanged code will readily be swapped to disk anyway, that is simply the way the Linux kernel works, it will keep the data in memory and just make a note of the disk address for the unchanged program so perhaps that is what you are talking about?
Nicktheprofessor said:
It's known as half-precision floating point and it can improve performance in some cases and save cache space but you still have 64 bit code and 64 bit memory allocation.
You can't fix that without actually rewriting code.
---------- Post added at 03:32 AM ---------- Previous post was at 03:27 AM ----------
Well you could just edit the init files and not have ZRAM at all but still support for it in the kernel, the phone will still work just fine but i sincerely doubt you will see much improvement.
Also the cache speeds are not slow in the least, i don't know where you get that from considering that decompression is done on the fly using the fastest algorithm possible and uses all available cpu's. I don't think you can improve on that much.
SWAP space on this phone is ZRAM, there is no physical memory put aside to do that job so...
However, unchanged code will readily be swapped to disk anyway, that is simply the way the Linux kernel works, it will keep the data in memory and just make a note of the disk address for the unchanged program so perhaps that is what you are talking about?
Click to expand...
Click to collapse
For improvement in speeds you would see a nice gain if you disabled ZRAM as the recent apps you are using will be in RAM instead of swap(flash storage). We both know that flash storage for as fast as it is is still way slower than RAM. You can test this yourself by disabling ZRAM and setting swappiness to 0 and then opening up a few apps and switching between them. It is noticeably faster. Also, ZRAM compression on the 5X is done exclusively on the small cluster by default (source: https://android.googlesource.com/device/lge/bullhead/+/master/init.bullhead.rc#69)
I understand that swap space is from ZRAM. I also made a mistake with the second part of that statement as I was thinking at the time that ZRAM compresses RAM to use for swap space when it actually compresses some of the flash storage to use for swap space.
ZRAM doesn't use flash.
https://en.wikipedia.org/wiki/Zram