Improve performance for loading files

[tobiasdiez]

• Performance improvements around groups
• Remove detection of duplicate ID when inserting entries (it's not really possible to create two entries with the same except if you use setId manually)
• Remove detection of duplicate bibtex keys when opening a file (the result was not used and we have a integrity check for it)
• Use EnumMap instead of HashMap to cache fields as keywords (which is only used for Keyword and Groups fields anyway)
• Fixes Formatting of main table ignored #6329 where latex code was displayed in the maintable
• Lazy init of source tab

In summary, we are now at very reasonable numbers:

• Reading files is about 1k entries per second (with 30% spent on initialing the EventBus)
• Groups membership counter is still expensive to calculate but kind of ok (30 sec for 1k groups x 12k entries = 12 mil checks)
• 7s load of an empty JabRef instance
• 1gb ram with two databases of together 15k entries

(all numbers are measured under profiling, thus they are worse than under actual production).

I think that concludes my series of performance improvements for now.

• Change in CHANGELOG.md described (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

[Siedlerchr]

Regarding, entries with the same id: What happens when you have a shared database? @koppor

[tobiasdiez]

jabref/src/main/java/org/jabref/gui/collab/EntryChangeViewModel.java

Lines 48 to 50 in 3a899d8

	database.getDatabase().removeEntry(oldEntry);
	BibEntry mergedEntry = mergePanel.getMergeEntry();
	mergedEntry.setId(oldEntry.getId()); // Keep ID

That's the only instance where setId is invoked and since the old entry is removed shortly before, there is really no chance of duplicate id.

[koppor]

Regarding, entries with the same id: What happens when you have a shared database? @koppor

In general, we have the sharedId at the communication with the server - to ensure that two users always have the same id for the same entry.

[koppor]

Thank you for getting rid of the pseudo primary key.

I have some minor comments on the other changes. I also pinged @stefan-kolb because of the InteralFields. Maybe @LinusDietz could also comment on that, because he worked on that on JabCon, too.

[tobiasdiez]

Thanks for the reviews. I (hopefully) addressed each concern and updated the code accordingly.

[calixtus]

Great work!

I recently thought about another way to make user experience more responsive: The database tab could be opened, before the parser starts working. This would need some more refactoring (maybe moving the call to the import routines inside the tab constructor?). This would be a project in the mid future.

[tobiasdiez]

That's indeed a very good suggestion @calixtus. Let's keep it in mind.

[koppor]

@calixtus Could you please open an issue for it. Seems to be a good-first-issue? (And link this PR from the description there)