RAM Usage on Client Machine

Development
1

The whole point of the Network is not to have data need to be stored to disk, right? Also, due to the cost of transmitting data throughout the Network, using the least amount of GETs is encouraged, correct?

So my thought is, where is this data stored when it’s being operated on?

###The simple answer is RAM.

But how much RAM can be consumed by that data, and how long can data persist in one machine?

The first question has to take into account the Launcher and the App itself along with the data that it’s acting on. The second is a bit more vague, because it must facilitate multiple use cases.

There I’m mainly concerned with the point of view that I don’t want every press of the “back button” to require a re-download of the data concerned. Should every rewind of a video necessitate re-downloading the frames? How far in advance should it be buffered? You can extrapolate this as you will - however, this is not a concern when using the Network as a dropbox replacement, but rather an app-centric environment.

###Launcher RAM cap

If this is indeed - as I see it - an issue, there may be the ability for the Launcher to institute a RAM cap. Now that may be per-app or globally, but I would envision something of the sort acting similarly to caching in nodes.

###Caching

Speaking of which, caching does do this by default. Well, it kinda does it. While it is seen as a way to reverse the “reddit hug of death” paradigm, in this scenario it (presumably) significantly reduces download time for recently accessed files.

However, this does not do away with the need to re-download files that - while they may be most recently accessed - are no longer being acted upon by the app. This still add (perhaps unnecessarily) to the amount of GET requests on the Network.

###Per-app config

Every app will have different needs for file retrieval and re-retrieval. This may just be left to the whim of the developers for them to ensure a reasonably efficient program.

While this may seem bad as there is no strict control by the user, this does incentivize similar apps to be competitive in their respective footprint size in a balance with their efficiency.

###Swap

As a last note, there may be a maidsafe “swap” or “.tmp” rationale that is implemented to save data directly to disk for the duration of the App - or longer. This would need to be controlled - most likely via Launcher - to be kept within an acceptable, user-defined limit.

###Conclusion

While this may not be a problem for a casual user, or even for a heavy user in the early stages of the Network, I do forsee that RAM usage by the Network and its Apps will be or become significant if not taken into appropriate consideration in an App-centric environment. There are several ways to mitigate this that are not - in themselves - mutually exclusive.

4 Likes
2

The reality is that every app owner will go for the maximum amount he can get, because he doesn’t need to pay for the RAM.

Another reality is that as long as you have access to source code, you’ll be able to set the cache to a minimum.
Or run Safe Network in a small VM.

So users who have a clue will control their resources, and those who don’t will have them devoured by greedy app devs.

3

I see your logic, but it is not what happens in practice.

It’s not hard to see why, it’s because any app that does this will quickly be identified and exposed as a system hog, and be shunned by users because using it would make using everything else sluggish to impossible. So in practice we can see that developers put effort into reducing their demands on the system.

You can accurately say: “system resources (such as RAM) cost them nothing”, but to only consider that ignores the impact of this behaviour has on users, and the users’ response to that.

3 Likes
4

Well Chrome is the most popular browser and it requires a ludicrous amount of RAM.
FF isn’t much better.
People may run or not other apps, but these hog browsers are never shut down by most.

1 Like
5

There’s a difference between what an app takes and hogs all to itself, and what it uses according to what the user “demands”, and when spare RAM is available.

The best applications use RAM sparingly, but increasingly as needed according to what the user is asking them to do. So with a browser for example, it uses a certain amount of RAM when you start it, and each tab you open consumes more. It’s then a matter of users realising that closing tabs frees RAM if their machine is getting slow. Some operating systems or apps help users by suggesting when this might help.

Saying Chrome uses a ludicrous amount of RAM ignores this, gives a false impression IMO, and so is not very helpful.

EDIT: you also ignore that there are of course browsers that use less RAM (at the cost of functionality), so again it’s incorrect to suggest that “developers” or “apps” as in all developers or all apps, will consume all the RAM available because it is free.

1 Like
6

3 GB is definitively a ridiculous amount of RAM in today’s terms.
Browsers could close or expire content of tabs which haven’t been active for 5 mins, but they don’t do that.
So an already ridiculous 30 MB for an empty tab becomes, and stays, 100 MB for an inactive Web page that doesn’t do anything while taking up 2 or 4 % of your total system RAM.

I don’t ignore that there are browsers that use less RAM (I am not using Chrome at the moment, for example).

Everyone knows there must be simpler browsers than use less RAM, but uses use Chrome despite that. Do they ignore that Chrome is RAM hungry? I think they do.

Developers could choose to download or refresh pages slower and save RAM, but they don’t want to (because they don’t have to - browser is usually the last app to be closed). People find value in saved time, but not all would be willing to pay such a high price. But there are no options to deal with that except to keep the number of open tabs below 8 or 4.

7

Damn! How many porn tabs do you have open!? I’m surprised you have enough energy to type… :cold_sweat:

JK. :sweat_smile:

That’s true. Of course as you know people respond to reviews and personal experiences. Slow buggy memory hogging bullshit == garbage to be avoided. Chrome gets away with memory gorging because most systems now come with abundant RAM and benefits from googles’ cache which speeds page retrieval. Users almost always opt for speed above resource usage. Especially when it isn’t long term/permanent. SAFE on the other hand is a resource based system that rewards its users for proper budgeting. Encouraging efficiency. This I believe will help weed out careless devs.

1 Like
8

I don’t think so. Battery technology has advanced so slowly compared to the increasing power demands of CPU/RAM/disk access.

Just search the web for “facebook app battery life” and you’ll see how passionate people are when their apps drain too much power.

The mobile facebook app was entirely rewritten IIRC, purely because it was so inefficient.

9

There is no plan to have a mobile SAFE client as far as I know, that’s why my comment didn’t consider mobile scenarios.

10

I believe the mobile SAFE client has been planned since the network’s inception, but I’ll agree and say that a mobile client won’t be ready for the upcoming alpha.

The MaidSAFE github repository also shows several recent commits by @ustulation to the “android” MaidSAFE port branch. Seemingly that android branch is geared towards the odroids you hear about on here, but the legwork for a mobile client is there.

1 Like
11

This browser RAM hog issue and the value of RAM to the network is another reason for a SAFE browser and a SAFE browser on mobile. Mobile is so crucial but so is IOT. But we also need mobile that cuts the cord.

12

Arch support is one thing, power consumption is another.
It will be a while before one can run MaidSafe on phones for over couple hours before running out of juice.
Personally I am not even considering doing that since I don’t use mobile phone for much except phone calls, so I didn’t give it much thought, though.