Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JabRef performance issues with large bib file #1094

Closed
simonharrer opened this issue Apr 4, 2016 · 9 comments
Closed

JabRef performance issues with large bib file #1094

simonharrer opened this issue Apr 4, 2016 · 9 comments
Assignees

Comments

@simonharrer
Copy link
Contributor

JabRef version 3.x on Windows 10

Steps to reproduce:

  1. Create BibTeX file with 100000 entries. (automatically generated using a ruby script)
  2. Open with JabRef
  3. Wait for nothing to happen for a few minutes
  4. JabRef opens but is very unresponsive.

test.zip

@tobiasdiez
Copy link
Member

Well, the loading time was acceptable for me (< 1 min) but JabRef uses 2 GB of memory :). Will have a look at it.

@tobiasdiez tobiasdiez self-assigned this Apr 4, 2016
@stefan-kolb
Copy link
Member

There are several things that can cause this problems:

  • Autocompletion performance is not optimized

@simonharrer
Copy link
Contributor Author

You could try to profile it using jvisualvm which is shipped with Java. The script which generates the bib file is available since 1edd7d3

@Siedlerchr
Copy link
Member

You could also try Java Mission Control (part of jdk)
http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html

@tobiasdiez
Copy link
Member

I actually plan to write a few benchmarks using JMH. So we have a reliable way to later gauge if some changes improve the performance or not.

@simonharrer simonharrer mentioned this issue Apr 4, 2016
3 tasks
@stefan-kolb
Copy link
Member

For me, save as takes ages when selecting a crowded folder. Dunno if this is somehow related to JabRef or only Java in general.

@koppor
Copy link
Member

koppor commented Apr 26, 2016

The first benchmarks have been done in #1103.

@stefan-kolb
Copy link
Member

Close this for now? We got significantly better on the major points didn't we?

@simonharrer
Copy link
Contributor Author

There is still room for improvement. But as far as I know it is good enough at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants