Improve startup time

[tobiasdiez]

trafficstars

Tracking the most expensive operations when starting JabRef yields the following picture:

This shows that the following can be improved:

• [x] First peak (500ms): do not load the group pane from fxml but create controls directly in the code. Done in #8035.
• [ ] Second peak (500ms): lazy initialization of the source pane in the entry editor (creating of the code area is expensive)
• [ ] Third peak (1300ms): This is comes only from passing the group name through the latex2unicode converter. Performance wise it's better to a) directly convert the group name to latex when the user adds/edits a group or b) cache the display name already in the Group and not only in the GroupViewModel which might be re-created a few times.

The other peaks correspond to things that need to be there (parse of bib file, init of webview in the preview panel,...).

[AEgit]

Maybe this proposal could be incorporated here as well: https://github.com/JabRef/jabref/issues/6042 ?

As far as I can tell, the calculation of the item count in the groups panel has a massive impact on the performance for large databases.

[koppor]

Third peak ideas:

• Rewrite latex2unicode - Refs https://github.com/JabRef/jabref/issues/5547 and https://github.com/JabRef/jabref/issues/3644 (this is I wanted to take care of)
• Use Google Guava's cache - with a callable --> https://github.com/google/guava/wiki/CachesExplained#from-a-callable (I know, we had the discussion and caching with Guava was never making sense. Nevertheless, I had the idea again)

[github-actions[bot]]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!

[AEgit]

I am not aware of that any of the above-mentioned suggested changes have been included (there have been performace-related improvements which were very welcome at the time - but I do not think the specific issue mentioned here have been tackled), so I reckon this issue is still present it:

JabRef 5.2--2020-12-09--d1fb9e2 Windows 10 10.0 amd64 Java 14.0.2

[koobs]

It would be great to have the method that produced the OP flamegraph in JabRef docs. I googled for a while on call graph / flamegraph analysis stuff for Java apps on Windows / MacOS and came up relatively empty handed.

@tobiasdiez can you detail (even in simple step form) how you produced them?

That would make it easier for people to analyze performance, make suggestions (or better, produce PR's), and help users to reproduce / report performance issues (I'm trying to do that now for an unrelated performance issue)

[Siedlerchr]

We use YourKit Java Profiler https://www.yourkit.com/java/profiler/download/ (free trial avaiable)

[ilippert]

As this is still open, I like to link it to the meta issue – https://github.com/JabRef/jabref/issues/8906

[ilippert]

I am now at JabRef 5.8--2022-08-05--b2125ad Linux 5.18.16-200.fc36.x86_64 amd64 Java 18.0.2 JavaFX 18.0.1+2

Upon starting JabRef, it takes regularly 2 to 2.5 minutes to get a responsive JabRef window. Till then my OS (Gnome) asks me whether I want to stop the software.

I test this with large libraries open (+10k entries).

Without large libraries open, at the least, it is swift. So, when I open JabRef only with a small library, I get fast startup; when I then open a large database, I at least get a visual indicator (turning wheel like thing) that something is happening.

[calixtus]

2-2.5 minutes is definitely way too long. Starting jabref takes my machine 2-2.5 seconds.

[calixtus]

We are planning to reimplement database loading on jabcon in September. This maybe won't speed up the process at first, but should make it more responsive.

[ilippert]

Sorry, I do not want to mess things up, but it may be good to note that this old issue that might be linked or might be closed - https://github.com/JabRef/jabref/issues/5362

[ilippert]

Hi there, a brief update on my current experience of staring up JabRef with two libraries opened, one with +10k, one with 1.5k.

I am regularly needing round 20 seconds to load these libraries.

Currently on JabRef 6.0--2023-01-03--f8c2cf6 Linux 6.0.15-300.fc37.x86_64 amd64 Java 19.0.1 JavaFX 19+11

but it also was like this before.

Though my hard drive is not the fastest. Yet, typically, the system tells me during these 20-25 secs that JabRef is unresponsive.

Screencast from 2023-01-04 11-39-47-b.webm

[ThiloteE]

Interesting video. If you refrain from clicking the button to "Force quit / wait", will it continue to load? Will the popup freeze loading?

[ilippert]

Interesting video. If you refrain from clicking the button to "Force quit / wait", will it continue to load? Will the popup freeze loading?

JabRef will continue to load and work successfully later. So, the video reflects the issue that seemingly JabRef is unresponsive, even though JabRef continues to work...

[calixtus]

Current profile of startup time:

JabRefGUI.start

Launcher.main