Improve startup time - Githubissues

tobiasdiez commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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)

AEgit commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

ilippert commented 2 years ago

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

ilippert commented 2 years ago

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 commented 2 years ago

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

calixtus commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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

ilippert commented 1 year ago

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 commented 7 months ago

Current profile of startup time: grafik

JabRefGUI.start CPU-flame-graph

Launcher.main grafik

JabRef / jabref

Improve startup time #6057