• What is your experience with Samsung "RAM Plus" virtual memory expansio

    From Andrew@21:1/5 to All on Thu Dec 5 06:08:49 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to Andrew on Thu Dec 5 10:26:34 2024
    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 ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arno Welzel@21:1/5 to All on Thu Dec 5 22:57:37 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Edward.C@21:1/5 to Andrew on Fri Dec 6 13:40:20 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to Edward.C on Fri Dec 6 08:05:54 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arno Welzel@21:1/5 to All on Fri Dec 6 09:55:16 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Slootweg@21:1/5 to Andy Burns on Fri Dec 6 11:51:56 2024
    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.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Java Jive@21:1/5 to Edward.C on Fri Dec 6 11:52:29 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Frank Slootweg on Fri Dec 6 14:02:36 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrew@21:1/5 to Carlos E.R. on Fri Dec 6 21:21:33 2024
    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".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arno Welzel@21:1/5 to All on Sat Dec 7 13:51:45 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Slootweg@21:1/5 to Arno Welzel on Sat Dec 7 13:14:24 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to Frank Slootweg on Sat Dec 7 14:05:15 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Slootweg@21:1/5 to Andy Burns on Sat Dec 7 16:18:03 2024
    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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arno Welzel@21:1/5 to All on Mon Dec 9 00:46:19 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arno Welzel@21:1/5 to All on Mon Dec 9 00:50:36 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)