Jabref requests at start 0.1TB virtual memory and uses 600MB RAM. As a comparison reference, my whole system has a 200GB SSD for two operational systems with approx 20GB free space at the moment. Even though VIRT seemingly does not equal RAM + swap space, I find this value alarming. The 600MB RAM usages is also kind of borderline to me, but it is not an issue yet.
I’ve just started to use JabRef and I’ve got 620 entries in my database, which could increase by a magnitude in a short time. I am also afraid how much the RAM usage will increase once my database is extended. I feel that jabref is slow, the web searches often just hang, and my computer is also slowed down when JabRef is opened.
All in all, first I would like to get some feedback from others, whether they also experience such high memory usage.
Second I would like to know whether it could be a version specific problem, which will be fixed in the next release/build,
Third, whether there are ways to improve its memory consumption and performance by some user settings.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27933 zoltan 20 0 0,101t 594,6m 152,6m S 5,3 7,5 0:59.35 JabRef
Jabref version info:
JabRef 5.0--2020-03-06--2e6f433
Linux 4.15.0-96-generic amd64
Java 13.0.2
thanks for the feedback. We recently improved the performance and memory consumption in the latest development version: https://builds.jabref.org/master/
Pleas remember to make a backup before trying out the new version
Hi Christoph,
Unfortunately I see no change with JabRef 5.1--2020-04-23--bbea7df
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24908 zoltan 20 0 0,101t 742,4m 157,8m S 4,6 9,4 0:57.02 JabRef
The core of my bibtex library was imported from Mendeley. I think I did not altered the default settings in JabRef. Is ther any way I could debug what does it cause the the high memory consumption?
JabRef 5.2--2020-12-24--6a2a512
Linux 5.4.0-62-generic amd64
Java 15.0.1
It is stated in /proc/<PID of jabref>/status, that VmSize: 6189944 kB right after starting it up. It opens my default and only database. It is just by start requiring 6GB memory.
In my case (also running Linux), I had to deactivate “auto completion” in settings. Afterwards only about 300 MB Memory with 5 bib files with about 3000 entries open.
Thanks for the hint! Though I am not sure whether I’ve found it in the settings. It is not in the menu-like preferences, but there is something in a variable-value list attached as a screenshot. Is it where you have disabled the auto-completion? Auto-completion seems to be turned off there…
Sorry for the unclear wording, I have no idea how these interfaces are called.
Ahh, OK Thanks! It was already turned off in my preferences. Probably that’s why I’ve overlooked this. I was looking for something I can turn off.
The reason behind the sluggishness and the memory consumption seems to be something else in my case.
I am hoping to get some advice how to improve the memory consumption. Right now it requires 300GB virtual memory and it reserves itself 1.8GB after a fresh start. So the situation has even worsened. I have no idea how it is possible to represent the whole database which is a less than 2MB file even 1.8GB. If there is any extra feature which is not necessarily required for operation, I would like to know how to disable it.
When I have JabRef open in the background for multiple hours I see a java process with more than 1 GB memory usage. That number keeps increasing and the biggest I’ve seen was over 4 GB.
I have 36 entries, where most of them have a linked PDF file. In sum those PDF files are 150 MB.
This is my JabRef version:
JabRef 5.3--2021-07-05--bed9ac9 Linux 5.4.0-72-generic amd64 Java 16.0.1 JavaFX 16+8
I gave it a try. From the first view impressions I would say it’s a bit worse (I’m sorry).
Right after the start memory consumption increased from 360 MB to 480 MB.
After clicking on the first entry the consumption goes straight to 1.0 / 1.1 GB in both versions.
JabRef 5.4–2021-10-06–bbc67ed
Windows 10 10.0 amd64
Java 16.0.2
JavaFX 17.0.0.1+1
With empty library:
after start it uses roughly 200 - 240 megabyte RAM
Creating one entry in the library and entering the entry editor leads to:
jump to roughly 570 - 620 megabyte RAM usage.
Deleting the entry or closing the library:
leads to jump towards 650 - 700 mbyte.
Restart of JabRef.
Opening my library with 79 entries:
265 - 280 megabyte RAM. 310 when scrolling.
Clicking on one entry to open the entry editor:
600 - 620 megabyte RAM.
RAM increases the more entries i click on or select via my keyboard arrows. It starts increasing with15-20 mbyte steps, then becoming incrementally smaller (e.g. 5-10, 0-5) until hitting roughly 830 mbyte of RAM usage. Then it basically stopped deviating. I have not tested letting the machine run for
multiple hours. Might do at one point.
Measurements taken with the in Windows built in “Task-Manager”
Edit:
While doing the measurements, these were my settings:
I did not have any pdf files attached to any entry
The development version contains a full text pdf search. JabRef creates an index in the background the first time you open the library. However, once it’s crated it should not be causing any huge problems
While memory savings are nice, because it reduces the minimum hardware requirements to run JabRef, nowadays in the year 2024, I am having a different view on RAM usage. RAM is relatively fast. For certain workloads it is better to put stuff into RAM (or map it there) instead of keeping it on the harddrive (HDD/SSD), which has a slower read/write speed. JabRef has received many new features in recent years, therefore, unlike what users might first associate it with, increased RAM usage is not just a phenomenon of unintended bugs and inefficiencies, but rather the opposite. It is the result of making the best out of what hardware is available to users of JabRef. New features usually means more things JabRef can do, but it also means “more code” and more processes that have to run in the background, so yes new features can cause more ram usage, but that’s ok. RAM is currently cheap, when compared to the price of a good CPU or GPU.
Does RAM usage increase with greater availability, like I have read about browsers, and is there a simple way for users to recognise if JabRef is using “too much”?
It’s easy for someone who is not so familiar with JabRef’s internals to wonder why it takes as much RAM as it does. Currently, that is 1.7 GB on my system, down from 2.4 GB a moment ago, with a library of 1300 entries. VSCodium was using 1.4 GB with the same library, two copies of it, and several other files open and plugins running. I started a Clojure REPL to add a JVM to the comparison in and RAM usage climbed to 1.9GB in Codium.
The only application on my system that continually uses more RAM than JabRef is Firefox. More important, though, is that the other applications remain responsive when JabRef does not, so I have been under the impression that the difference was related to inefficiencies or something more “external” such as display scaling and graphics drivers (Nvidia Optimus + Wayland).
RAM is currently cheap, when compared to the price of a good CPU or GPU.
True. My system is using about half the RAM is available, so I am not concerned about that. I would like a better CPU or GPU, but the only upgrade about to happen is new thermal paste, which might make a difference.
This depends on the application and the operating system that is used.
JabRef is using too much, if you don’t have free space anymore for other applications to run, unless you simply don’t have state of the art hardware, then maybe it is not the problem of JabRef, but having outdated hardware instead. If you look at hardware diagnostics and see that your RAM usage exceeds the RAM available to you (e.g. if you can see that RAM usage is at 95 - 100% and lots of HDD/SDD read and write operation exist and your swap space is used as well), then you might want to look into ways to acquire more RAM or cut down on the applications in active/passive usage. If you are good at coding, you could look into ways to reduce RAM usage in your applications, but it might be cheaper to simply buy more RAM, when you compare the time invested to fix software with the price it takes to buy more RAM.
Thanks! It was already turned off in my preferences. Probably that’s why I’ve overlooked this. I was looking for something I can turn off.