RAM cache


  • Banned

    It would be nice if Vivaldi saved its cache to RAM. RAM is faster and it would clear after closing Vivaldi. Great feature for safety conscious people. And for people with SSDs. Currently Vivaldi is very unfriendly for small SSDs (lots of small writes and big cache files).



  • @hondac:

    It would be nice if Vivaldi saved its cache to RAM. RAM is faster and it would clear after closing Vivaldi. Great feature for safety conscious people. And for people with SSDs. Currently Vivaldi is very unfriendly for small SSDs (lots of small writes and big cache files).

    There is already a plenty of people who are very unhappy about chromium's memory footprint, I am sure storing cache in RAM will make the issue only worse.

    Plus I seriously doubt you would actually notice the difference between keeping chache on SSD and in RAM.



  • RAM caching is hard to implement with a multi-process design. Chromium basically uses the disk as shared memory, just like old MS-DOS applications did :P



  • -1 here
    RAM filling is the reason I stopped using Chrome

    But if it was an option, that's be fine



  • @jtsn:

    RAM caching is hard to implement with a multi-process design. Chromium basically uses the disk as shared memory, just like old MS-DOS applications did :P

    I believe that would be pretty easy to make cache's path customizzable, letting the users to place it on a ramdisk, but I believe there are more urging things to fix/implement before start to think to tweak the basics of chromium.



  • I have to say that while the original Chrome releases were shouting about how separate processes was good for stability, the more I get to use the engine in Vivaldi, and the more I read about others' experiences here, the more I question the wisdom of that design choice.

    (And to think people would troll the Opera forums about Presto's memory usage!)

    I'm hoping that with time the Vivaldi team will be able to work on undoing this process separation - although presumably that would mean donating their work back to the Chromium project.



  • Processes on Windows are costly, only threads are lightweight, while on Linux forking into a new process is almost free. This was the base of this design choice, because Google doesn't really care about Windows. Their main platform for this browser is of course ChromeOS.

    So the smart choice for a Windows browsers would spawning a new process for each N unrelated tabs. Also one could run all extensions in a single, but separated process, because we don't really a separate process for each user script.

    Of course, the RAM cache has be an extra process and memory shared between all other processes. I think, you wouldn't even notice the memory footprint, if you just add another cache process with something like 50 MB of RAM to the whole thing.


  • Banned

    I can't even see the cached files. Just some generic files and not the actual files downloaded.

    @YemSalat:

    There is already a plenty of people who are very unhappy about chromium's memory footprint, I am sure storing cache in RAM will make the issue only worse.

    Noone would notice few more MBs more taken by the already RAM hungry Chromium/Blink. And you would be able to limit it's size unlike the disk one and it will clear on exit.

    @YemSalat:

    Plus I seriously doubt you would actually notice the difference between keeping chache on SSD and in RAM.

    I would notice difference between cache on HDD and RAM (if Chromium/Blink actually used it).
    But moving cache to RAM would serve different purposes. One of them is privacy (cleaning on exit).
    But the biggest problem is that Chromium/Blink literally kills SSDs (with writes).
    (https://vivaldi.net/en-US/forum/technology/3450-hidden-truth-about-ssds)

    I hope Vivaldi team will improve the atrocious caching mechanisms - primarily less writes and smaller files.



  • @mossman:

    I have to say that while the original Chrome releases were shouting about how separate processes was good for stability, the more I get to use the engine in Vivaldi, and the more I read about others' experiences here, the more I question the wisdom of that design choice.

    There was no wisdom in that design, only laziness! I'm using Firefox Nightly x64 v41 atm and it uses ~500MB for 28 tabs and has been running for almost 10 hours straight! Opera 29 on the other hand, which has been open for the same amount of time on the same machine, is using almost 1.5GB of RAM just because of this design!

    I've been using chromium based browsers for a couple of years now, never in my life have I experienced 1 tab crashing without crashing the whole browser with it. I've experienced it on Nightly like 2 days ago and it's using threads instead. I really can't see the stability in that design. Blink is fast and all that but this is stupid.

    I'm ok with Vivaldi using Blink instead of Gecko, but as someone who uses more than 20-30 tabs daily, it frustrates me.



  • @GrandGamer:

    I'm ok with Vivaldi using Blink instead of Gecko, but as someone who uses more than 20-30 tabs daily, it frustrates me.

    Memory use is killing me. If I open 20-25 HTML stock charts at once my 8GB RAM is about maxed out and the system bogs horribly (a few other programs running too). Each chart tab consumes 250-300MB. Obviously I need more RAM in the meantime while I pray the RAM usage can be improved. I really want to run 50+ tabs at once.



  • @jtsn said in RAM cache:

    Processes on Windows are costly, only threads are lightweight, while on Linux forking into a new process is almost free. This was the base of this design choice, because Google doesn't really care about Windows. Their main platform for this browser is of course ChromeOS.

    So the smart choice for a Windows browsers would spawning a new process for each N unrelated tabs. Also one could run all extensions in a single, but separated process, because we don't really a separate process for each user script.

    Of course, the RAM cache has be an extra process and memory shared between all other processes. I think, you wouldn't even notice the memory footprint, if you just add another cache process with something like 50 MB of RAM to the whole thing.

    It doesn't matter if processes on Linux are almost free, Vivaldi memory usage is very high on my Linux. And note that I do have a 2016 laptop with standard good specs and I'm running Solus with Budgie as DE and usually only have Vivaldi open so my system's very lightweight. I even tweaked some Vivaldi parameters and flags as suggested in various threads but memory usage is still too high per process. So no, it doesn't matter that processes on Linux are almost free.


  • Vivaldi Translator

    @Motionshot
    I live with Vivaldi with 2011 Core2 Duo 2.40GB, 3GB ram, nVidia EN8600GT 512mb, Linux/Debian sid amd64. Plenty of extensions running, 10+ tabs (still under 20). Some other programs also open.
    HTOP show 99% ram with 3 digits swap file after I visit some busy sites or just badly designed. But all the time only 30~50% if those site are calm.

    Would you believe I never got real problems?


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.