Before Joplin I used notepad++ to store notes and other stuff, it usually consumed maybe 35 MB of RAM and was very quick and I leave it running 24/7.
But I noticed Joplin consumes from 250 - 800 MB of RAM! At one point I was editing settings and it was around 800 MB.
That is as much as an additional Chromium browser running in background without any plugins..
When clicking on a note and editing, it goes up to 450MB and stays that way as long as window is open.
When X is pressed, it becomes a background app and uses around the same amount of RAM.
So after using Joplin for a while, this is not something I want to leave running in the background all day long.. Especially if people use laptops way more these days on battery power, I doubt this is an app for them. I have enough RAM, but it's just too much for a simple note app.
Joplin 1.7.11 (prod, win32)
I have a sync enabled with dropbox and encryption.
Win 10, 64b.
Strange that so many of these note apps are using electron...
I have already tried multiple from alternativeto website. I tried out Typora (also electron app, lacks tabs and easier overview which Joplin has), Standard Notes (another electron app), Simplenote (another electron app) which required sign in immediately, and Obsidian note app and it consumes as much as N++. Has the same features and even more, but lacks encryption and sync with cloud storage.
Joplin can't change the RAM requirements of Electron or how Electron uses memory.
The only way to reduce memory usage is opening tickets with Chromium and Electron. But I can tell you right away, it will be like talking to a wall. But who know, maybe you get lucky.
Also, please note. Notepad and Typora are editors. Joplin is not. Joplin includes an editor.
But yes, I agree, it would be nice if Joplin were to use less memory. Unfortunately there's nothing we can do.
Not really sure how to answer that. I don't make the decisions but if I did, I propably would say that the chances are infinitesimal.
Personally I don't really like javascript. However, I haven't found a framework to build an app for all platforms that is any better. Moving to a new framework now would be extremely complex. I'm not even sure if one could estimate the man-hours required. It probably would be more in the range of several man-months.
Hey, if you find a framework that is written in Go and runs on Linux, macOS, and Windows, maybe you'll find 20 devs that are willing to rewrite Joplin.
However, don't forget: frameworks always have an overhead. In Electron this overhead is called Chromium. Doh, an entire browser engine....
Well, there's VS Code that is also built on top of Electron but is crazy fast and has lower memory footprint while having way more functionality. But then, it's backed by Microsoft and its army of developers.
It is certainly possible to optimize Electron apps, e.g. there's Neon that lets you write modules in Rust (and similar projects for other languages) and integrate them into Electron apps. I have tried it and it was surprisingly easy to use.
You can add Evernote to that list. Users who updated to v10 have noticed the memory usage.
If even EN cannot compete in the note app space without switching to a common codebase across platforms, there's no way for smaller apps to do so - they would get left in the dust by apps that could add a feature across all platforms at once.
To Joplin's defence I've got a lot of notes and plugins, so I'm kinda unintentionally pushing it. I guess that's a new tax we got to pay for using cross platform apps.
To kind moderators, please not be triggered, I'm not complaining, and not asking for help, the pic is here just to share the information and is not intended as a critique of some sort, although if you're eager to investigate the issue, be welcome to my DM.
I think the issue is that even if we used a non-Electron framework, it would still need to have a webview and multimedia capabilities. The rich text, interactivity, audio and video player, PDF viewer, printing, platform integration, etc. we take that for granted but the Electron team put a lot of work into this. We could use Qt's webview to render the notes and text editor for example, but it's also quite big (last time I checked they use WebKit) and not as fast, secure and well supported as Chromium.
So yes there's still no alternative. And not using a webview means we'd have to implement it ourselves - basically implementing a webview ourselves which of course would be insane.
I've seen Joplin use very large amounts of RAM (under Kubuntu 20.10) but when I've quit the program and restarted it it was using much less. Days later (I sleep the computer rather than turning it off) Joplin's RAM usage is still very reasonable. I am guessing certain activities in Joplin may be causing high memory use and not Joplin in general. Has anyone else seen that?
Forgive my ignorance on Electron and the like. But is there really no way to select which libraries get added to the final app - either at compile or at runtime ?
... first in general, for the standard app, or second for a Joplin light version if the user doesn't need multimedia and / or other features ? Half a GB up to all the way to 1GB RAM is no joke.
how much RAM do you have? In 1998 I had about 32Megabytes. Since circa 2018 I have 32GB.
RAM is cheap, I recommend to spend some and upgrade!
Note: Joplin compared to Evernote v10 is super-slim, mega fast and extremally efficient.
Yes I also wonder if it's really an issue. I have a bunch of Electron apps running all the time and it doesn't look like they take more RAM than non-Electron apps, do they? Thunderbird and Vivaldi take more RAM than Joplin or Discord for instance on my computer:
Anyway aren't operating systems these days more efficient at managing RAM too? Like even if it reports that the app takes 1GB, that might be 1GB reserved but not effectively used, and some of it would be available if the system runs out of memory.
I don't think this is a good approach. If every app developers thought this we wouldn't be able to use our computers - a gigabyte here, another one there, and your 32GB are all gone.
