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)