"Samsung RAM Plus is a feature found in certain Samsung smartphones
that creates virtual RAM by using a portion of the device's internal
storage to provide extra temporary memory when the actual RAM is
running low."
I didn't even realize this existed until now
Andrew wrote:
"Samsung RAM Plus is a feature found in certain Samsung smartphones
that creates virtual RAM by using a portion of the device's internal
storage to provide extra temporary memory when the actual RAM is
running low."
I didn't even realize this existed until now
Sounds like a swap file, but doesn't android already use zram for
swapping? Not played with (or needed to play with) kernel stuff in
android for years ...
To help another user on another thread I checked my settings to show him
how an inexpensive phone can have enough horsepower to be just fine, I happened to go into my settings & saw a Samsung setting for "RAM Plus". Settings > Battery & device care > Memory > RAM Plus = on/off
When I looked at the RAM Plus in my Samsung Galaxy A32-5G, it showed:
(_) 2GB
(o) 4GB
Looking up what the heck Samsung RAM Plus even is, I find this cite: <https://www.simplymac.com/android/what-is-samsung-ram-plus-is-it-worth-it> "Samsung RAM Plus is a feature found in certain Samsung smartphones
that creates virtual RAM by using a portion of the device's internal
storage to provide extra temporary memory when the actual RAM is
running low."
I didn't even realize this existed until now (or maybe I knew at one time
and forgot) but what I'm asking here is what is your experience with it?
I think it depends on your usage. If you always have many apps running
at the same time, maybe it can give slight improvement in performance.
I have disabled it and never noticed any difference, probably because I
have 12GB of RAM on my A55.
Edward.C wrote:
I think it depends on your usage. If you always have many apps running
at the same time, maybe it can give slight improvement in performance.
I have disabled it and never noticed any difference, probably because I
have 12GB of RAM on my A55.
Given the way Android apps save their state and are then ready to be
killed when there is pressure on memory, ready to be reloaded "as they
were", then using swap seems a bit pointless?
Edward.C wrote:
I think it depends on your usage. If you always have many apps running
at the same time, maybe it can give slight improvement in performance.
I have disabled it and never noticed any difference, probably because I have 12GB of RAM on my A55.
Given the way Android apps save their state and are then ready to be
killed when there is pressure on memory, ready to be reloaded "as they
were", then using swap seems a bit pointless?
I have 12GB of RAM on my A55.
Andy Burns <usenet@andyburns.uk> wrote:
Edward.C wrote:
I think it depends on your usage. If you always have many apps running
at the same time, maybe it can give slight improvement in performance.
I have disabled it and never noticed any difference, probably because I
have 12GB of RAM on my A55.
Given the way Android apps save their state and are then ready to be
killed when there is pressure on memory, ready to be reloaded "as they
were", then using swap seems a bit pointless?
Yes, but not all apps can be killed and reloaded/restarted "as they
were". For example those which depend on external data or/and state. For those apps, you want them to be swapped instead of killed.
After all, we still use paging (and possibly even swapping) on real computers, don't we? If all programs/processes would be killable/
restartable without data/state loss, we wouldn't have to do that.
That said, on my Samsung Galaxy A51 Android 13 with 4GB RAM, 'RAM
Plus' is enabled and set to 4GB (other choice is 2GB). I don't think
I've set that, so I assume it's set when the device is 'Checking...'
when you tap the 'Memory' entry. (Currently, it says 2.7GB of 4GB used,
762 MB available, 525 MB reserved.)
Funny the different names used across different brands. Of course, my
phone is in Spanish, but even so it is not the same menus.
Andy Burns <usenet@andyburns.uk> wrote:
Edward.C wrote:
I think it depends on your usage. If you always have many apps running
at the same time, maybe it can give slight improvement in performance.
I have disabled it and never noticed any difference, probably because I
have 12GB of RAM on my A55.
Given the way Android apps save their state and are then ready to be
killed when there is pressure on memory, ready to be reloaded "as they
were", then using swap seems a bit pointless?
Yes, but not all apps can be killed and reloaded/restarted "as they
were". For example those which depend on external data or/and state. For those apps, you want them to be swapped instead of killed.
Frank Slootweg, 2024-12-06 12:51:
Andy Burns <usenet@andyburns.uk> wrote:
Edward.C wrote:
I think it depends on your usage. If you always have many apps running >>> at the same time, maybe it can give slight improvement in performance. >>>
I have disabled it and never noticed any difference, probably because I >>> have 12GB of RAM on my A55.
Given the way Android apps save their state and are then ready to be
killed when there is pressure on memory, ready to be reloaded "as they
were", then using swap seems a bit pointless?
Yes, but not all apps can be killed and reloaded/restarted "as they were". For example those which depend on external data or/and state. For those apps, you want them to be swapped instead of killed.
By definition an app *must* support the fact, that it can be killed at
any time. Even rotating the display will kill and restart the current
running activity. That's the reason, why dialog boxes should not be used
but UI fragments instead since the state of fragments will be handled by
the OS instead of the app.
But on the other hand it depends on the app developers how good the
implement state changes.
My/the point is that not all appscan be designed that way. It might
be thatif they can be designed that way, theymust be designed that
way. But an app developer can not be required to do the impossible.
Note that I specifically mentioned external data or/and state. If an
app is killed, external data or/and state might/will be lost and the app cannot recover when restarted. Examples of such apps are apps which
depend on data from (internal or external sensors or other data
sources).
Frank Slootweg wrote:
My/the point is that not all appscan be designed that way. It might
be that if they can be designed that way, they must be designed that
way. But an app developer can not be required to do the impossible.
Note that I specifically mentioned external data or/and state. If an
app is killed, external data or/and state might/will be lost and the app cannot recover when restarted. Examples of such apps are apps which
depend on data from (internal or external sensors or other data
sources).
They can save the most recent sensor values as part of their state, so
if they get killed, they can use the saved value rather than re-reading
the value from the sensor.
Arno Welzel <usenet@arnowelzel.de> wrote:
Frank Slootweg, 2024-12-06 12:51:
Andy Burns <usenet@andyburns.uk> wrote:
Edward.C wrote:
I think it depends on your usage. If you always have many apps running >>>>> at the same time, maybe it can give slight improvement in performance. >>>>>
I have disabled it and never noticed any difference, probably because I >>>>> have 12GB of RAM on my A55.
Given the way Android apps save their state and are then ready to be
killed when there is pressure on memory, ready to be reloaded "as they >>>> were", then using swap seems a bit pointless?
Yes, but not all apps can be killed and reloaded/restarted "as they
were". For example those which depend on external data or/and state. For >>> those apps, you want them to be swapped instead of killed.
By definition an app *must* support the fact, that it can be killed at
any time. Even rotating the display will kill and restart the current
running activity. That's the reason, why dialog boxes should not be used
but UI fragments instead since the state of fragments will be handled by
the OS instead of the app.
But on the other hand it depends on the app developers how good the
implement state changes.
My/the point is that not all apps *can* be designed that way. It might
be that *if* they can be designed that way, they *must* be designed that
way. But an app developer can not be required to do the impossible.
Also note I mentioned in the part you snipped, if all apps/programs
could be designed that way, we wouldn't have paging/swapping on real computers, but we do. Guess why that is?
Andy Burns <usenet@andyburns.uk> wrote:
Frank Slootweg wrote:
My/the point is that not all appscan be designed that way. It might
be that if they can be designed that way, they must be designed that
way. But an app developer can not be required to do the impossible.
Note that I specifically mentioned external data or/and state. If an
app is killed, external data or/and state might/will be lost and the app >>> cannot recover when restarted. Examples of such apps are apps which
depend on data from (internal or external sensors or other data
sources).
They can save the most recent sensor values as part of their state, so
if they get killed, they can use the saved value rather than re-reading
the value from the sensor.
Yes, but they will miss the sensor data that was generated between the
time the app was killed and when it was restarted. Think tracking/
Like I said, if paging/swapping wasn't needed, computers wouldn't have those functionalities, because one 'disk'-access (load-only) is faster
than two (page/swap out and back in).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 498 |
Nodes: | 16 (2 / 14) |
Uptime: | 09:06:45 |
Calls: | 9,822 |
Calls today: | 1 |
Files: | 13,757 |
Messages: | 6,190,746 |