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

Entry preview: Display delayed for large databases #5735

Closed
AEgit opened this issue Dec 11, 2019 · 27 comments
Closed

Entry preview: Display delayed for large databases #5735

AEgit opened this issue Dec 11, 2019 · 27 comments
Labels
entry-preview status: stale status: waiting-for-feedback The submitter or other users need to provide more information about the issue type: performance

Comments

@AEgit
Copy link

AEgit commented Dec 11, 2019

JabRef 5.0-alpha--2019-12-11--c3b7ee7
Windows 10 10.0 amd64
Java 13.0.1

In the current dev version of JabRef the entry preview is no longer displayed - it is just a white field.
Untitled

@AEgit
Copy link
Author

AEgit commented Dec 11, 2019

Ok, update to the problem: The entry preview will appear, if you wait for 5 to 10 min. This appears to be coupled with the performance problem reported here:
#5734

The entry preview reappears if you wait 5 to 10 min after starting JabRef. At the same time, the CPU load drops to zero.

@Siedlerchr
Copy link
Member

Do you use one of the CSL styles (not the "Preview" )?

@AEgit
Copy link
Author

AEgit commented Dec 11, 2019

No, I only use the default preview, i. e. I have made no changes to the "Current Preview" options under "Entry preview".
Untitled

@Siedlerchr
Copy link
Member

Hmm this is odd. Might be related to #5622 (comment)

@AEgit
Copy link
Author

AEgit commented Dec 11, 2019

Update 2: Ok, so it seems I can narrow down the problem a little bit. If I use a database, that has been stored using the old release version JabRef 3.8.2 and then open it with the current developer version of JabRef 5.0, the problem appears as described above.

Now, if I save this database with the developer version of JabRef 5.0, close it, and then reopen it with the developer version of JabRef 5.0, the entry preview will still not appear immediately. But instead of having to wait 5 to 10 min, it only takes about 30 sec until the actual entry preview (instead of the white background) is shown.

@tobiasdiez tobiasdiez added this to the v5.0 milestone Dec 11, 2019
@tobiasdiez
Copy link
Member

30 sec for the preview is still too long, and the database size shouldn't matter for this.

@AEgit
Copy link
Author

AEgit commented Dec 11, 2019

Note, that with the following older version, the entry preview is immediately displayed, irrespective of whether the database still has the old 3.8.2 format or the new 5.0 format:

JabRef 5.0-alpha--2019-12-04--5dcb565
Windows 10 10.0 amd64
Java 13.0.1

@bernhard-kleine
Copy link

bernhard-kleine commented Dec 14, 2019

with the latest dev version from today it works:
The DOI is added by editing the standard (and only) preview template.
grafik

@AEgit
Copy link
Author

AEgit commented Dec 14, 2019

JabRef 5.0-beta.1--2019-12-14--2e056e6
Windows 10 10.0 amd64
Java 13.0.1

@bernhard-kleine Cannot confirm. With a database with nearly 20,000 entries, it takes about 30 secs before the entry preview is displayed (using the 5.0 format - with the 3.8.2 format it takes much longer as explained above). Note, that the following older development version of JabRef would display the entry preview immediately:

JabRef 5.0-alpha--2019-12-04--5dcb565
Windows 10 10.0 amd64
Java 13.0.1

@AEgit AEgit changed the title Entry preview no longer displayed Entry preview: Display delayed for large databases Dec 14, 2019
@tobiasdiez tobiasdiez removed this from the v5.0 milestone Feb 23, 2020
@Siedlerchr
Copy link
Member

This should be much faster now in master and will be improved further by the work of @michel-kraemer

@AEgit
Copy link
Author

AEgit commented Feb 27, 2020

JabRef 5.0-beta.497--2020-02-27--3e0284d
Windows 10 10.0 amd64
Java 13.0.2

@Siedlerchr
Cannot confirm - as reported here (#5510 (comment)) the performance is now even worse than before. It is now so bad for large databases, that I cannot test bug reports/fixes on my large database. JabRef behaves as if crashed most of the time. Please reopen this issue.

@AEgit
Copy link
Author

AEgit commented Feb 28, 2020

@Siedlerchr : Do you already have a large database (with thousands of entries and thousands of static groups) to test/confirm this issue or do you need me to send one? If the latter is the case, I can try and send one - but since I cannot to make the database available to the public, we would need to find a way around that.

@Siedlerchr
Copy link
Member

I could experience some issues with loading (I think it was based your library) ( we have it internally only avaiable for the developers). However, once JabRef has opened the library the preview generation of differnt styles was fast. And also no problems with drag and drop of groups. Tested in Windows 10

@bernhard-kleine
Copy link

I have tested it with a library of ~16000 entries, while selecting all entries took some time, displaying the preview was immediate.
I can not reproduce the problems @AEgit meets.

@AEgit
Copy link
Author

AEgit commented Feb 29, 2020

@bernhard-kleine
Ok, this is weird. Are you able to open a database with 16,000 entries immediately or does it take a lot of time the first time you open the database? How many groups (displayed in the groups view) does your database contain?

@bernhard-kleine
Copy link

10 seconds for opening aside my standard library. Since the large library is not used much the group panel is almost empty.

@tobiasdiez
Copy link
Member

This bug may be fixed in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks! Please remember to make a backup of your library before trying-out this version.

@tobiasdiez tobiasdiez added the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Apr 20, 2020
@AEgit
Copy link
Author

AEgit commented Apr 20, 2020

JabRef 5.1--2020-04-20--bc57d22
Windows 10 10.0 amd64
Java 14.0.1

more than 20,000 items + several thousands of static groups

@tobiasdiez : It takes about 90 sec to open the database and see the entry preview. The main table (without the entry preview) is shown after 60 sec, i. e. it still takes about 30 sec to show the entry preview after the main table is already visible. Is that acceptable? Once the the library is fully loaded, the performance is definitely better and the issue mentioned in one of the follow-up comments (#5735 (comment)) has disappeared.
But the original (modified) issue still persists as reported here: #5735 (comment) (I have only tested with a v. 5 version of the database).

@bernhard-kleine
Copy link

bernhard-kleine commented Apr 20, 2020

win7 jabref snapshot 2020-04-18 library 3246 entries:

It takes 6 seconds to open jabref and further 12 seconds to load the library (with entry preview). Very similar with the 2020-04-20 snapshot.

@AEgit
Copy link
Author

AEgit commented Apr 24, 2020

JabRef 5.1--2020-04-23--bbea7df
Windows 10 10.0 amd64
Java 14.0.1

more than 20,000 items + several thousands of static groups

Performance has further increased. Well done!

  1. Clicking on the JabRef icon and waiting for the main table to appear takes about 13 sec.
  2. The entry preview is shown after an additional 20 sec (total of 33 sec since the icon was clicked).
  3. CPU load decreases after another ~15 sec (total of 48 sec since the icon was clicked).

This is a massive improvement compared to previous dev versions. The load up speed is now the same, no matter whether a database in the new v5 format or in the old v3.8.2 format is being used.

@github-actions
Copy link
Contributor

This issue will be closed in 7 days due to inactivity 💤 Please provide the requested information if the problem persists.

@AEgit
Copy link
Author

AEgit commented May 25, 2020

Reaction to github-actions bot:
I am not sure, whether this issue should be closed - I report the current situation here:
#5735 (comment)

If people are happy with this performance, then you can close the issue. But there is definitely still a delay until the entry preview is shown - JabRef 3.8.2 has no such delay.

@AEgit
Copy link
Author

AEgit commented Jun 3, 2020

JabRef 5.1--2020-06-02--46fd96b
Windows 10 10.0 amd64
Java 14.0.1

Quick update: If you disable the groups item count as implemented in the current dev version (#6042), the entry preview is shown immediately (or there is a a delay of max. 1 sec) once JabRef has opened. For people with very large databases (>20,000 entries) and several thousands of groups, this change in preferences can definitely improve the performance of JabRef during load up.

@github-actions
Copy link
Contributor

github-actions bot commented Jul 4, 2020

This issue will be closed in 7 days due to inactivity 💤 Please provide the requested information if the problem persists.

@AEgit
Copy link
Author

AEgit commented Jul 5, 2020

Second reaction to github-actions bot:
I am not sure, whether this issue should be closed - I report the current situation here:
#5735 (comment)

If people are happy with this performance, then you can close the issue. But there is definitely still a noticeable delay until the entry preview is shown, if the group item count is displayed. If it isn't, the delay is max. 1 sec, which I reckon people would be fine with.

@bernhard-kleine
Copy link

bernhard-kleine commented Jul 6, 2020

For 3264 entries about 7 sec, for 16620 entries without heavy grouping no delay.

@github-actions
Copy link
Contributor

github-actions bot commented Aug 6, 2020

This issue will be closed in 7 days due to inactivity 💤 Please provide the requested information if the problem persists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
entry-preview status: stale status: waiting-for-feedback The submitter or other users need to provide more information about the issue type: performance
Projects
Archived in project
Development

No branches or pull requests

4 participants