Improve startup time

[tobiasdiez]

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

This shows that the following can be improved:

• First peak (500ms): do not load the group pane from fxml but create controls directly in the code. Done in Improve startup time #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:
#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 LaTeX to Unicode and vice versa has stopped working #5547 and Rework superscript: latex-to-unicode and unicode-to-latex roundtrip not working #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)

[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 – #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 - #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

[InAnYan]

That WebView... I thought about using WebViews for AI features, but I was feared of performance. Turns out it is true, as initialization WebView takes nearly 1/5 of JabRef startup time.

I think we can easily switch from WebView to Text and JavaFX styles. But then we will run into issue, that we can't copy text (how many good features this limitation ruins).

JabRef has some WebView management techniques, but it sill uses WebView.init(), so no luck there

[InAnYan]

#6057 (comment)

Oh wait, what am I saying.

We just need to lazy load it.

Just when preview is first triggered add a spinner there

[InAnYan]

Small talk

Emacs-nerds typically do this: they start Emacs in background as a service/server.

When they need to open Emacs they use emacs-client and just connect to server.

[koppor]

JabRef has some WebView management techniques, but it sill uses WebView.init(), so no luck there

We went to single-load for preview at #12165.

Maybe this a place for you to start working on the spinner.