JabRef 4.2 freeze on Windows 10


(Bernd Szyszka) #1

Hi, I’m using this version of JabRef:

JabRef 4.2-dev–snapshot–2018-01-31–master–97ee2e966
Windows 10 10.0 amd64
Java 1.8.0_162

During editing, the systems slows down tremendously. After a while, it freezes. The CPU load ist > 90 % and the memory usage is > 1000 MByte. What is going wrong? How to improve? I’ve had the same problem also with JabRef 4.1. The situation is very frustrating since I really need my database. I’d appreciate any suggestions.

Best regards

Bernd


(Bernd Szyszka) #2

Hello to the JabRef community,

I wonder about my problem of very slow performance of JabRef 4.2 compared to the 3.x version. What is the reason for this? How to improve? Is it possible to switch off some features to achieve the former performance?

Best regards

Bernd


(Bernd Szyszka) #3

Hello,

I’m still searching for the reason why JabRef is so slow on my system. Can it be related to the Java version? On my system, I’m using:

JabRef 4.2-dev–snapshot–2018-02-08–master–9ab29d596
Windows 10 10.0 amd64
Java 1.8.0_162

However, there is also a Java 9 installation on the computer. What is the best way to configure for a fast system? For example, how to turn off the automatic identification of PDFs.

I have a database with 12 000 datasets, with hundreds of keywords. It’s large, but not that large, I assume.

I’d appreciate any hints on my problem.

Best regards

Bernd


(Tobias Diez) #4

Hello Bernd,

with > 10.000 entries a memory footprint over 1 GB ram is expected (I wouldn’t be surprised to see it climbing over 2 GB). However, the CPU should only work hard when you load or save the database (or run integrity check/cleanup) but not when JabRef is idle or when you only edit a single entry. Do you always hit 90% CPU load?

Do you have many groups? They might slow down JabRef for large databases, especially the “automatically generated” ones.

You may also try out the version here: https://github.com/JabRef/jabref/pull/3621. It’s a very early build and some features are still missing but the performance should be better.

Hope this helps a bit…


(Bernd Szyszka) #5

Hello Tobias,

thank you for comment! I’ve downloaded that version and indeed, the performance is better. The memory usage for ~12 000 datasets is ~750 MByte, I don’t use automatic groups but a lot of groups defined manually.

Best regards

Bernd


(Bernd Szyszka) #6

Hello Tobias, hello all,

I’m still struggeling with the poor perfromance during editing. The program is much to slow for an efficient work flow. I wonder how to improve the situation. Would there be a chance to switch off and automatic features? Like the search for the pdfs etc.? I just need performance during simple editing - not more. Any support on this would be of great help for me.

Best regards

Bernd


(Tobias Diez) #7

Hey Bernd,
I’m sorry to hear that you still experience these performance issues. To be honest, I’m not sure what’s the reason for this. JabRef does not many things in the background, and the few things it does are usually not tied to input in the entry editor. So the following suggestions are a bit a shot in the blue, but maybe they help:

  • Changing fields in the entry editor triggers an automatic safe of the database. For big db’s this may take a while. Maybe it works better if you disable the automatic backup in the preferences.
  • The group tree gets updated as soon as an entry changes. For testing purposes, you could make a copy of your database and remove all groups.
  • The suggestions for the auto completion are also updated as soon as something change, so maybe disable auto completion may give you a bit better performance (but to be honest, I doubt it).

(Bernd Szyszka) #8

Good morning Tobias,

thank you for your message, but I think, your topics have not been of help. I’ve uploaded my preferences, where I’ve turned off most things allready. Anything missing to turn off?

During editing, it’s not only the editor window which gets the data, it’s the whole database at the same time. I feel, that might be the problem. Entering an author list may take 5 minutes or so, since the system is almost freezing.

I’ve not tried to remove the groups yet, but the system is slow even without touching any group related actions. I think, in version 2.x I have not oberserved such problems. In version 3.x, it was already difficult.

preferences_2018-03-02.xml (10.8 KB)

This is the version I’m using now:

JabRef 4.2-dev–snapshot–2018-03-01–maintable-beta–3710be843
Windows 10 10.0 amd64
Java 1.8.0_162

Do you have debugging / performance monitoring tools to identify the routines which consume the CPU power?

Best regards

Bernd


(Christoph) #9

Hi,

regarding performance debugging you could take a look at Visual VM. It’s the standard jdk tool.
You could also ask @halirutan (https://github.com/halirutan) He has previously done some performance measurements.

https://visualvm.github.io/index.html

Regards
Christoph


(Bernd Szyszka) #10

Dear Christoph,

thank you for your feedback. I’ll try this.

Best regards

Bernd


(Pedro Aphalo) #11

Hi, I have been suffering from other instabilities and problems when using Jabref in recent times, clearly related to settings. I think I have found one cause of trouble. Just raised an issue at https://github.com/JabRef/jabref/issues/4003
but in brief, in my case, backslashes in the Main directory path setting seem to have been the problem. Manually replacing backslashes with forward slashes seems to have restored normality, although it is still too early to be sure that this was the main issue.
Best regards,
Pedro.


#12

Dear all,

I’m experiencing similar problems as Bernd on Windows 10 (with Jabref 4.2 stable). I have a database with 6700 entries and many groups. RAM use and CPU load is similar to Bernd too.

Unfortunately changing the main file directory form backslash \ to forward slashes / didn’t help in my case (at least I couldn’t feel an improvement).
Best regards
Heiko


#13

Dear all,

as written to aphalo below I’m experiencing similar problems as Bernd on Windows 10 (with Jabref 4.2 stable). I have a database with 6700 entries and many groups. RAM use and CPU load is similar to Bernd too.

  • disabling automatic backup in references didn’t help in my case

  • disabling auto completion in preferences didn’t lead to felt improvement

  • Removal of all groups helped a lot: RAM use dropped approximately from 1700 - 1800 MB to approx. 800 MB. At the same time CPU use by Jabref (which was also easily 90 % before, slowing down the system a lot and making filling in of fields a rather long lasting work and using the whole system was not a pleasure) is now reduced to around max. 30 %. So it is much better (first impression). So for example now Jabref is opened with the database and without doing anything in there CPU is at around 30 %.

Question: Jabref now looks automatically for files. So if a create a new entry it suggests me a file which name is identical to my bibtexkey. Could this function slow down the system too? Is there an option to disable this “auto automatic file link search” so that Jabref only starts looking for file if I start the process (e. f. F7) to do so.

So I will try now if the reduction of my groups (because some of them are very helpful) will help to have lesser freeze.

Best regards

Heiko


(Christoph) #14

@heiko The automatic look for files is only triggered if you are in the General Tab of the entry editor at one entry.


#15

@Siedlerchr Thanks a lot for the explanation!


#16

@all

As (in my case) the groups seem to be one reason for slowing down JabRef and the whole computer system, do you think that switching from “dynamic grous” using search terms in specific fields to “static groups” might be a compromise between using the group function without slowing down the system to heavily?

For many of my orginal groups I could do such a change.

Best regards
Heiko


(Bernd Szyszka) #17

Dear all,

for my system, the change of slashes in the path directory to forward slashes gave indeed an improvement! No, I can work again with the system. It’s still slow comared to JabRef 2.x, but again usable. Thanks Pedro for this comment!

Best regards

Bernd