Jabref is extremely slow on MacBook Air with macOS 10.14.5 (18F132)

Hello, I’ve downloaded Jabref for macOS but I can’t use it because it’s extremely slow.
I thought that this was a Java problem, but I tried with both Java SE 12 and Java SE 8 without any success.

How can I solve this problem?

Thank you in advance.

Which version of JabRef do you use? The latest development version includes a few huge performance improvements.

Hi, I’ve downloaded the latest version, but the problem still persists…

I second that.
Since Jabref 5.0 nothing seems to be right for Jabref on Mac. It has been a workhorse for 10+ years for me and I am close to giving up. Any news if some sort of improvement can be expected?

@Vasileios_Gkinis Have you tried the latest development version 5.2.x?
(It’s recommneded to make a backup before trying out the new version)
And maybe can you give some more details when or where the performance is down. Do you use many groups? How large is your library? The more concrete the better.
We are constantly working on JabRef and also have been focusing on performance especially in 5.1.
However, keep in mind that all developers only work in their spare time for JabRef.

Hi Christoph
I am on 5.1. Have not tried the dev version you are referring to
Switched back to 4.9 (ish) at some point but decided to give it one more try with 5.2 …bad luck so far.

I have about 900 entries - most of them with a pdf linked to them
8-10 groups.
I am on osx 10.15.7
I love the way jabref works together with anything latex/bibtex and the simplicity is key for me.
Hope things will get better with performance. Right now it is unfortunately a struggle
Good luck and thanks for all the great work until now.

@Vasileios_Gkinis is every action slow? I have never used JabRef with a library of that size, the largest one I can try is 210 entries (and no linked pdfs) and everything except opening and scrolling is smooth (JabRef 5.1, Mac OS X 10.15.7)

pretty much yes. clicking simply on an entry results in a waiting time of 4-5 sec

Unfortunately, this isn’t enough information for me to help out. I wouldn’t mind taking a closer look at it but I can’t recreate the issue on my current setup

JabRef 5.1--2020-08-30--e023aa0
Mac OS X 10.15.7 x86_64 
Java 15

using the unmodified https://github.com/JabRef/jabref/blob/master/src/test/resources/testbib/jabref-authors.bib nor duplicating it to get 2520 entries.

Do you have the same performance issues on the jabref-authors.bib database?

I have a huge library here to test with thousands of entries and many groups (friendly provided by a user) and it’s not a problem.
It might help if you create a new library and copy over some entries.
There have been reports that when you open a file created by an older version of JabRef that this is slower than a library created by the new version.

Now on 5.2
Unfortunately no change. Still very slow
on top of that it looks like impossible to open a pdf from inside Jabref. All the references in my library are recognised but I still cannot find a way to get the pdf’s to open from inside JabRef.
I would like to help with more feedback if this is useful so please do let me know

@Vasileios_Gkinis Regarding the PDFs, please check the preferences (General file directory), there was an issue where the file directory setting was not set correctly after an ugprade.

Regarding the performance: Are you doing a search?

Please try to disable the Autocompletion

Hello everyone,

i can confirm the above mentioned problems. After updating to a current version of japref yesterday, all input clicks and reactions are very very slow, 3-4 sec. delay until an action is executed. I have two bib libraries. One with only a few entries (11) for a current project and a longer one with more entries (about 150). both show this behavior

JabRef 5.1–2020-08-30–e023aa0
Mac OS X 10.15.7 x86_64
Java 15

Best regards


In regards to occasional freezes on Mac OS X, there’s been an improvement with

Remember to save a copy of your database before trying out the changes in the latest development release,

@Vasileios_Gkinis @Chris @vrizz does the problem still exists?