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?

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 ...

Andy Burns, 2024-12-05 11:26:

> 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 ...

Yes, "RAM Plus" is swapping. ZRAM on the other hand is compressing data
within the RAM when it is not needed at the moment and uncompressing it
again when needed. So ZRAM is faster than swapping but does not give you
as much memory since data still remains in RAM, just in a different form.

--
Arno Welzel
https://arnowelzel.de

On 12/5/2024 2:08 PM, Andrew wrote:
> 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.

On 12/5/2024 2:08 PM, Andrew wrote:
> 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?

Andy Burns, 2024-12-06 09:05:

> 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?

It depends on the app. Loading and preparing data ready to be used after
being killed may take more time than just swapping in the memory contents.

--
Arno Welzel
https://arnowelzel.de

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.)

On 2024-12-06 07:04, Edward.C wrote:
>
> I have 12GB of RAM on my A55.

I read that first as "I have 12GB of RAM on my arse" ... could be
useful, I suppose.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On 2024-12-06 12:51, Frank Slootweg wrote:
> 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.

Yes, I am using swap. In Linux, it is used for hibernation, and when
there is memory pressure; my mini server uses it.

>
> 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.)

I looked up "memory" on mine, which is not Samsung but Motorola, and
there is no memory entry in the config. I found "performance" (under
system), and on this I saw "intelligent application start (enabled)" and
"RAM improvement" (disabled). The later says "if there is enough
storage, use some to enlarge the RAM".

Device memory: 6GB
memory expansion 1.5GB (greyed out)

This must be swap. There is a switch to enable it.

It doesn't say how much ram is in use, except with graphic bar; I
estimate 5 GB are in use.

So I search instead for the word "RAM". Size of ram is found under
"about the phone", "hardware info". Again, it doesn't say how much is in
use. It also mentions there is 128 GB of ROM.

Funny the different names used across different brands. Of course, my
phone is in Spanish, but even so it is not the same menus.

On the storage chapter, my phone has 128 GB, of which the beast is
applications (61 GB). Photos are just 11 GB, videos 6.2 GB. I have two
large applications: OsmAnd+ (17.97 GB) and Pocket Casts (15.41GB). The
later is a surprise. To my knowledge I am subscribed to only one
podcast, which I have configured so save automatically, so that I can
listen with no network. But I had no idea they were taking so much space.

Wasap is just 2.91 GB.

Ah... pocketcasts is also storing a second podcast, one of "books in one
hour" since May 2022 (one per week); older ones are listed, not stored.
I have now disabled auto download of this one.

--
Cheers, Carlos.

Carlos E.R. wrote on Fri, 6 Dec 2024 14:02:36 +0100 :

> Funny the different names used across different brands. Of course, my
> phone is in Spanish, but even so it is not the same menus.

There is also a section in my "Developer options" under "Memory" which, for
my Android 13 Galaxy A32-5G starts with a quizzical "number of hours".

Choices for memory times are: 3 hours, 6 hours, 12 hours & 1 day
Then it states "Average memory usage = 2.5GB"
Then Performance = Normal
Total = 4GB
Reserved = 572MB
Average usage = 73%
Available = 0.5GB

Then there is a section for "Memory usage" saying:
"61 processes used memory in the last 3 hours"

Which is probably what the "hours" are at the top (I guess).

When I click on that "Memory Usage" up comes a listing for the last "3
hours" (pretty much confirming what the time was at the top).

Android OS used 1.0GB average memory usage
Android System used 328MB average memory usage
System UI used 206MB average memory usage
etc.

The sort options are "maximum usage" or "average usage".

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.

--
Arno Welzel
https://arnowelzel.de

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.

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).

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?

Frank Slootweg wrote:

> 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).

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.

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/
tracing apps, activity trackers - including sleep tracking -, etc., etc..
For example the developer of Sleep as Android developed the
DontKillMyApp app [1]. Need I say more!?

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).

I'm sure there are many, many other applications where killing
processes just isn't an option. Actually the exact opposite, I think
there are few applications where killing the process(es) *is* acceptable
behaviour.

[1] 'DontKillMyApp: Make apps work'
<https://play.google.com/store/apps/details?id=com.urbandroid.dontkillmyapp>
Referenced from 'Tracking crashes, stops suddenly' on
<https://sleep.urbandroid.org/docs/sleep/automatic_sleep_tracking.html#after-fall-asleep>

Frank Slootweg, 2024-12-07 14:14:

> 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.

Android *will* kill app activities all the time. An app which can not
deal with that, is mostly useless since - as I explained - even rotating
the display will cause this. Yes, some apps just cope with that by
disabling display rotation as long as the main activity is in the
foreground.

Also see here:

<https://developer.android.com/reference/android/app/Activity#onCreate(android.os.Bundle)>

<https://developer.android.com/reference/android/app/Activity#onSaveInstanceState(android.os.Bundle)>

<https://developer.android.com/reference/android/app/Activity#onRestoreInstanceState(android.os.Bundle)>

[...]
> 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?

On "real computers" an application process will not be killed just
because you minimize a window. And paging also has nothing to do with
that either but is just the process to move RAM pages to a swap file if
not needed - regardless if there is a process running or not.

--
Arno Welzel
https://arnowelzel.de

Frank Slootweg, 2024-12-07 17:18:

> 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/

To keep things running in Android, there are *services* besides apps.
These don't get killed regularly and can be triggered by events like "x
seconds hev passed" or "location has changed at least 10 meters", "IP
packet was recieved" etc. but they may drain the battery if not properly
implemented.

[...]
> 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).

When paging was invented, it did *not* use regular file I/O but a
dedicated hard disc partition where RAM pages where written directly to
hard disc sectors which is *faster* than reading files.

--
Arno Welzel
https://arnowelzel.de