improve response when clicking on the general tab

[Processeer]

Description

• All linked files are on a mounted server, not on a local drive
• opening the general tab with a linked file to the distant folder results in a dealyed response
• switching between entries while general tab is open also resulsts in a delay
• opening the general tab while no file is linked shows no delay
• opening the File annotaions tab while a files is linked also results in a delay

It seems to me that the program always checks if the file exists before it returns the focus. In my [user] opinion it is not neccessary to know until I want to open the file. But to access any other field in this tab will also result in the delay.

JabRef JabRef 5.9--2023-01-08--76253f1a7 Windows 11 10.0 amd64 Java 19.0.1 JavaFX 19+11

[ThiloteE]

This can have various causes.

Things you can try:

1. Please try https://docs.jabref.org/faq#q-i-have-a-huge-library.-what-can-i-do-to-mitigate-performance-issues.

2. Please try to disable full-text search.

3. Please try to disable automatically indexing linked files for fulltext search:

Another thing would be to check if your server is well connected to your client device. See here: https://forum.openwrt.org/t/best-practices-and-tools-for-measuring-wifi-performance/146923. I can recommend Iperf3.

[ThiloteE]

Low priority for now. Debugging is needed, if this slowdown is not caused by very inefficient code. Discussion is needed. Is it worth not knowing, if links of linked files are broken? - See https://github.com/JabRef/jabref/issues/9731

[koppor]

@ThiloteE IMHO this is really about JabRef wanting to be "smart" to auto link files when the entry editor focuses an entry. This was introduced a few years ago. Some people liked this "smartness" of JabRef, some were wondering about it. -- I like the idea of checking file existence during opening of the file.

[Processeer]

if the community is 50/50 about liking it, what about making it optional in the properties? like indexing. Relinking is surely useful but could be a quality function. Files shouldn't be moved around all the time, right?

Checking a couple oft thousend files during opening might also take some time. The Option might be a drop down then offering

• never
• while opening database
• whenever an entry with a linked file is selected

personally I would like this very much.

[ThiloteE]

4th option for checking for file existence:

• whenever a linked file is opened

[mlep]

5th option:

• Quality -> Clean-up entry

And about "while opening database": should't be part of the Library -> Library properties menu?

[AEgit]

@ThiloteE IMHO this is really about JabRef wanting to be "smart" to auto link files when the entry editor focuses an entry. This was introduced a few years ago. Some people liked this "smartness" of JabRef, some were wondering about it. -- I like the idea of checking file existence during opening of the file.

Note, that adding the option to disable the auto-link feature was already suggested 4 years ago: https://github.com/JabRef/jabref/issues/5105 (not trying to be a smartypants but to showcase that there is, indeed, demand for such an option)

[koppor]

We worked on a fix today (see #9903 for details). Could you please try out https://builds.jabref.org/pull/9903/merge/.

[AEgit]

Hmmm, I downloaded the following version: JabRef 5.10-PullRequest9903.905--2023-05-16--f582ebd Windows 10 10.0 amd64 Java 20.0.1 JavaFX 20+19

But it does not show the option to toggle off the "Smart automatic linking of files" in the preferences section.

[koppor]

We moved it to the settings of the "Entry editor":

[Processeer]

JabRef 5.10-PullRequest9903.915--2023-05-16--bdd4b04 Windows 11 10.0 amd64 Java 20.0.1 JavaFX 20+19

on my engine it takes about 3s with or without enabling smart autolinking.

[ThiloteE]

@Processeer Unfortunate. I guess we need more info, do some more debugging and improve JabRefs performance further. :/

1. The first step would be to find out if you also experience these slowdowns, if the library files are stored on your local machine.
   • if yes: it is JabRef or your local machine.
   • if no: it is the connection to your server or your servers hardware.
2. it would be interesting to know if you use HDDs or SSDs (and if the harddrive's file read/write capabilities are maxed out)
3. and if your CPU is maxed out while opening the Entry editor or not.
4. In short: What are your hardware capabilities? If you own a PC with a name, providing the name would let us know about lots of your hardware.
5. Additionally, do you use wifi or cable? Is your server remote or within your local network
6. How many entries does your library file contain?

If you know how to use Intellij / Eclipse and have time and interest to debug this by setting up a local workspace, you could check where JabRef is stuck while opening the entry editor. See here for how to set up a local workspace it: https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace/ Maybe you have an IT professional at your place that you can ask.

[AEgit]

@koppor Cheers, now I found the setting (though personally I think it would be better to keep that setting in the "Linked files" section). As far as I can tell, the setting does, what it is supposed to do. Well done!

[Processeer]

fyi: very little time these days but I will check this as soon as I can.

[pratyushvatsalshukla]

@Processeer @ThiloteE I have been working on this issue . I have disabled the FullText Index Option by default. The functionality is working fine but, while i am trying to run test cases, 68/8290 test cases are getting failed. Any Suggestion from your side ?

[calixtus]

I'm against setting the default value of indexing to false. I think we also talked about that in a devcall a while ago, but Im not so sure about this. Reasoning was as I remember: The user should see the fulltext feature the first time using JabRef, but it is always possible, to turn it off. @koppor @Siedlerchr @ThiloteE Especially as I think the performance problems with opening the generals tab in the entry editor are not directly related to the indexing feature, because - as I understood the issue description - the performance problems also appear, even if there is no full text indexer running...

[ThiloteE]

I suggested to disable indexing as an initial form of debugging to find the real culprit for the slow response. Koppor and Processeer confirmed it could be that, but they never provided a hard proof and benchmarks, e.g. "with n number of linked files, during indexing entry editor is delayed by x seconds". Later we came up with multiple proposals how we could trigger indexing differently.

In the pull-request, @pratyushvatsalshukla chose the most radical (but easiest) approach and disabled it completely, while automatic indexing clearly is very convenient, albeit maybe probably slow with large databases (I have not tried it). Since most users do NOT have huge databases and a preference exists that allows to disable it, I would suggest to not disable indexing by default.

[ThiloteE]

There was a reason why this issue was labeled as "needs refinement" and "waiting for feedback" (by @Processeer).

[koppor]

@pratyushvatsalshukla I assume, you are on Windows? Please ask in the gitter chat, since your test issues are not related to this concrete issue.