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

Performance issues with version 5.0 (example videos) #5071

Open
AEgit opened this issue Jun 23, 2019 · 50 comments
Open

Performance issues with version 5.0 (example videos) #5071

AEgit opened this issue Jun 23, 2019 · 50 comments

Comments

@AEgit
Copy link

@AEgit AEgit commented Jun 23, 2019

JabRef 3.8.2
windows 10 10.0 amd64
Java 1.8.0_211

VS

JabRef 5.0-dev--snapshot--2019-06-20--master--6265e2460
Windows 10 10.0 amd64
Java 1.8.0_211

As announced previously (#4430 (comment)), here I add some videos that showcase the performance difference between JabRef 3.8.2 vs. JabRef 5.0 when working with a large database (> 18,000 entries) and several thousand static groups.

These issues have been reported previously, but I thought it would be better to create a new bug report instead of adding the videos to just one of these previous reports (they should apply to all of them, I reckon). Previous reports of issues with the performance include (among others), the following:

#4430
#4756
#4526

Note, that I had to run these tests on a virtual machine, since I do not have a full license for YourKit Java Profiler and had to use a test license (since the test license I had on my actual machine is no longer valid). So the performance on an actual machine should be slightly better (the virtual machine is running on a SSD, and I assigned two cores of a Core i7 Hexacore and 8 GB of 32 GB of RAM to the virtual machine), but the relative performance difference between version 3.8.2 and version 5.0 should be comparable. In fact, my impression is that this setup favours version 5.0 because 3.8.2 appears slower in the virtual machine than in a non-virtualized setting. Version 5.0 on the other hand, is equally slow in a virtual machine and when running on the actual hardware.

Note, that I use the same database when comparing the two versions. The only difference is, that the database in version 5.0 has been saved using version 5.0 (while the other one is still using a database in 3.8.2 format). This allows for better comparison, since version 5.0 stores groups differently.

  1. Comparison of first start of JabRef:
    3.8.2:
    https://app.box.com/s/7agrhreojpk85itl9dvsz7mx8ueaydcl
    5.0:
    https://app.box.com/s/79dqowjer214qdi0wiceh03x9g4iuexi

Note, that version 5.0 sometimes seems to have crashed. Furthermore, I did not immediately click onto 3.8.2 when it was actually already ready.

  1. Comparison of JabRef search feature:
    3.8.2:
    https://app.box.com/s/fgr84sgpsz6dscbnku91m5o2hhbf6rwt
    5.0:
    https://app.box.com/s/fxwcska8dm5rlilv6a9mqswelkrqkh0t

  2. Comparison of working with JabRef groups:
    3.8.2:
    https://app.box.com/s/fc5ku29f39o9r7h86hj309tao4uifo8o
    5.0:
    https://app.box.com/s/cubdi2vvmzjnj5i7rtn57lfxp24kvzb9

Note, how JabRef freezes several times in version 5.0 when using certain groups features (e.g., assigning an item to a group, assigning a group as a new subgroup, ....). Sometimes it appears as if nothing is happening in the video, but it is actually just JabRef freezing from time to time.
Note, the big differences in the time that JabRef spents on some actions (see YourKit Java Profiler). For certain actions, JabRef 5.0 will take much much longer than 3.8.2 (which translates into higher CPU demands).

@Siedlerchr Siedlerchr added this to Needs triage in Bugs via automation Jul 7, 2019
@Siedlerchr Siedlerchr added this to the v5.0 milestone Jul 7, 2019
@Codeberg-AsGithubAlternative-buhtz

#5156

@tobiasdiez tobiasdiez moved this from Needs triage to High priority in Bugs Aug 25, 2019
@tobiasdiez tobiasdiez mentioned this issue Oct 28, 2019
6 tasks
@tobiasdiez
Copy link
Member

@tobiasdiez tobiasdiez commented Nov 8, 2019

@AEgit the most recent developement version now includes the latest performance improvements. Could you please check what still needs improvement. Thanks!

@AEgit
Copy link
Author

@AEgit AEgit commented Nov 9, 2019

@tobiasdiez Due to the issues with the current Windows installer (see #5580 (comment)) and since the snap package on Linux also does not seem to work yet (see #5417) I cannot test the current developer version, I am afraid.

@LyzardKing
Copy link
Collaborator

@LyzardKing LyzardKing commented Nov 9, 2019

The snap can be installed from https://builds.jabref.org/master/
It won't auto update and you need to install with --dangerous (since it's not from the store)
But for testing it can be done.

@AEgit
Copy link
Author

@AEgit AEgit commented Nov 17, 2019

JabRef 5.0.0-dev--2019-11-17----151a216a2
Windows 10 10.0 amd64
Java 13.0.1

@tobiasdiez Tried the current dev version. This one is much improved in terms of performance. Switching between different groups and articles is now much smoother. Well done!

The following performance issues remain:

  1. Assigning an item to a group has a heavy impact on the CPU. Now, if you assign just a single item, this appears to be no major isse for a user with a powerful machine. I have a 6-core i7 and while the assignment of a single item brings the CPU usage to nearly 50% for a few seconds, the item appears (?) to be assigned immediately to this group (this might already be a problem, though, for people with weaker machines).
    What is a problem, however, is when you try to assign multiple items simultaneously to a new group. The CPU usage shoots up and (depending on how many items you try to assign to the group) JabRef freezes for some time. The CPU usage also stays high for a protracted time period: I am not sure, whether the items have already been assigned to the group as indicated by the item counter since the CPU usage stays high even after that for quite some time.
    To recreate this problem, try the following:
    a) Select multiple items in the main table
    b) Drag'n'drop them onto a group they had not be assigned to
    c) Observe the mentioned issues
  2. The same problem arises when you try to assign groups as subgroups of other groups (in fact, I think this feature might be bugged, but I have to test this more thoroughly). If you assign just a single group, things appear fine. But if you assign multiple groups simultaneously as subgroups to a new group (again, by using the drag'n'drop feature - but this time in the groups panel), you end up with a high CPU usage over a protracted period of time.
  3. When you select multiple groups in the groups panel simultaneously (using left click on the starting group and left click + SHIFT on the ending group), there is a noticeable delay until all groups are selected and the CPU usage shoots up again.
  4. There is a noticeable delay (a few seconds) when you select the "All entries" group until the respective items are shown in the main table. I reckon this is directly dependent on the number of entries assigned to a certain group, because this problem also appears to arise, when groups with a high entry count are selected (currently my "All entries" group contains nearly 20,000 items).

These are the performance issues I have observed so far. Nevertheless, again a big thanks to @tobiasdiez for the major performance improvements that the current version offers now - this is definitely a major step into the right direction.

@tobiasdiez
Copy link
Member

@tobiasdiez tobiasdiez commented Nov 17, 2019

Thanks for the feedback. I'll try to have a look at the remaining performance issues in the next days.

@AEgit
Copy link
Author

@AEgit AEgit commented Nov 24, 2019

JabRef 5.0.0-dev--2019-11-24----8780a5632
Windows 10 10.0 amd64
Java 13.0.1

Note also, that it appears, as if the search has become slower again. Not as bad as it was in the past (#2852), but it seems, that the latest versions have seen a performance decrease there as well. Entering a search term using a large database results in lagged input (similar to a low frame rate in a video game).

@Siedlerchr
Copy link
Member

@Siedlerchr Siedlerchr commented Dec 11, 2019

@tobiasdiez related to the add tab threading?

@tobiasdiez tobiasdiez self-assigned this Jan 1, 2020
@tobiasdiez
Copy link
Member

@tobiasdiez tobiasdiez commented Jan 18, 2020

@AEgit We implemented some performance improvements recently. Can you please see if they might have fixed some of the issues you described in #5071 (comment). Moreover, it would be good which of the remaining issues are critical, i.e. need to be fixed before we release 5.0. Thanks

@AEgit
Copy link
Author

@AEgit AEgit commented Jan 18, 2020

JabRef 5.0-beta.354--2020-01-18--2612e22
Windows 10 10.0 amd64
Java 13.0.2

The new versions brings some improvements, but the problems are still too big for a release version. I will explain this in detail below (based on the issues reported in #5071 (comment)):

  1. Now, if you assign multiple items to a single group, JabRef still has a high CPU usage (60%) over a protracted period of time (several minutes!), but it does not freeze anymore. However, now another issue can be observed. Namely, the cycling through entry previews does not work while the CPU usage is high. When you try to go from an entry preview of one item to the next one, the next item will be selected in the main table (indicated by the blue marking), but the corresponding entry preview is not shown. Instead, the entry preview of the previously selected item is shown. This means, that for several minutes (until the CPU usage has dropped from the item assignment to a new group) it is NOT possible to see the entry previews of all entries (except for the one, that had been selected initially).
    I think this is a major problem, that needs to be fixed before release.
  2. The problem with high CPU usage over time, if you assign a group as a subgroup of another still persists and appears to be even worse than before. I have just tried to assign one group as subgroup of another and that assigned another group as the subgroup of the previous one, i. e. we end up with a 3-leveled order: group - subgroup - sub-subgroup
    In total, just two groups have been moved. Despite that, the CPU usage stayed high for several minutes (!). It might be, though, that this problem only appears, if issue 1 has been triggered first, since I have not been able to trigger this behaviour consistently.
  3. Issue 3 appears to be fixed.
  4. The delay mentioned in issue 4 has been much reduced (it is now less than a second, as far as I can tell).
  5. When you now make changes to group structure (e.g., assign two groups as the subgroup of another group) and then selected another group again, NO items at all are shown in the main table. This means, that a few changed to the group structure lead to a non-functional main table (it just remains empty).
  6. The slowed down search persists (see #5071 (comment)).

I wonder whether some of these performance issues could be solved by a simple workaround: Make it possible to switch off the calculation of the number of items in the groups. In version 3.8.2 this was possible and was also suggested to do, when having performance problems. Indeed, I switched it off for my database, since otherwise it would not be possible to work with the database due to performance problems.
However, you shouldn't get rid of the background box surrounding the group item account. This box changes colour according to whether an item selected in the main table is part of a group or not, so this information should be available. In the old JabRef version this was achieved by having the name of a group underlined, which contained a selected item.

@ilippert
Copy link

@ilippert ilippert commented Mar 9, 2020

I have 10500ish entries; simply sorting the entry table by a column, e.g. title, takes typically several seconds.

JabRef 5.0--2020-03-08--93de138
Linux 5.5.7-200.fc31.x86_64 amd64
Java 13.0.2

@koppor koppor removed this from the v5.1 milestone Apr 14, 2020
@koppor koppor moved this from Closed to High priority in Bugs Apr 14, 2020
@ilippert
Copy link

@ilippert ilippert commented May 5, 2020

Not sure whether to report this here, or as a new bug.
I just deleted about 2000 entries from my 10600 entry database. It took about 4 minutes to complete this operation, meanwhile jabref was not useable.

JabRef 5.1--2020-05-04--7bb1e24
Linux 5.6.8-200.fc31.x86_64 amd64
Java 14.0.1

@AEgit
Copy link
Author

@AEgit AEgit commented May 5, 2020

JabRef 5.1--2020-05-04--b5599c9
Windows 10 10.0 amd64
Java 14.0.1

Can confirm the issue reported by @ilippert (#5071 (comment)). I just tried to delete >7,000 entries from a database with >20,000 entries. It took several minutes during which JabRef was not responsive so ultimately I decided to force shutdown JabRef since it seem to take way too long.

@ilippert
Copy link

@ilippert ilippert commented May 5, 2020

Let me add another performance report: I copied the 10500 entries of my database (the message of having copied the entries came after about 1.2 seconds, fine)). Pasting it into a new empty file took about 9 minutes.
meanwhile, jabref was not usable.

@ilippert
Copy link

@ilippert ilippert commented May 5, 2020

I have now disabled the timestamp and repeated the operation of creating an entirely new database. copying and pasting the >10500 entries was much swifter: 23-26 seconds.

@ilippert
Copy link

@ilippert ilippert commented Jun 5, 2020

Just to ask those who are part of this conversation: does anybody of you also experience that jabref does not cleanly shut down and uses high amounts of CPU? I noted that about a week ago ... #6559

@AEgit
Copy link
Author

@AEgit AEgit commented Jun 5, 2020

@ilippert : I have not come across this issue, but I should also mention, that:
a) I usually run JabRef on Windows (rarely on Linux)
b) I do not use the current dev version 5.1 in a productive environment, but version 3.8.2 (I cannot switch before the following feature request is implemented: #4237). So I am only testing version 5.1 for a short period of time. I don't know whether this contributes to the fact that I cannot reproduce the behaviour that you describe.

@m-mauersberger
Copy link
Contributor

@m-mauersberger m-mauersberger commented Sep 29, 2020

Performance issues persist for me when using a large database (~5000 entries) as well: database operations take ~5-10s. I want to use it as shared DB but the problem is the same for local and shared databases (see also #4461). Even if no changes are present, reloading of (shared) database takes the same time!

Maybe it has something to do with the EventBus? Just as a quick idea: Can it be the reason for slow down that each entry has its own EventBus and the listening methods are "overcharged"?

@ilippert
Copy link

@ilippert ilippert commented Jan 7, 2021

Recent versions of JabRef have worked well for me.
but
JabRef 5.3--2021-01-07--129abaa
Linux 5.9.16-200.fc33.x86_64 amd64
Java 15.0.1

seems very slowly reacting (takes several seconds to switch between entries in entry table). Although the use of the system's resources is fine.

@ilippert
Copy link

@ilippert ilippert commented Jan 8, 2021

Recent versions of JabRef have worked well for me.
but
JabRef 5.3--2021-01-07--129abaa
Linux 5.9.16-200.fc33.x86_64 amd64
Java 15.0.1

seems very slowly reacting (takes several seconds to switch between entries in entry table). Although the use of the system's resources is fine.

Ok, today under
JabRef 5.3--2021-01-07--aef49f4
Linux 5.9.16-200.fc33.x86_64 amd64
Java 15.0.1
JavaFX 15.0.1+1
it works well again ;)

@ilippert
Copy link

@ilippert ilippert commented Jan 27, 2021

JabRef 5.3--2021-01-24--ae43548
Linux 5.10.9-201.fc33.x86_64 amd64
Java 15.0.2
JavaFX 15.0.1+1

When starting up, JabRef needs 60-70% of CPU. It then goes down to 0% If I don't do anything. When selecting an entry it goes up to 2-3%. Switching a library goes up to 7%. Well, this might be normal operations. Adding a few lines in some entries. And then CPU use goes up to 60, 70, >80%! Closing JabRef then does not stop the process.

@tobiasdiez
Copy link
Member

@tobiasdiez tobiasdiez commented Jan 27, 2021

Thanks for the report. Do you remember the last version were you didn't experienced these problem?

@ilippert
Copy link

@ilippert ilippert commented Jan 27, 2021

Thanks for the report. Do you remember the last version were you didn't experienced these problem?

Unfortunately, not exactly. If it helps, I would say last week. (If there was a repository with all the last 2 week's master builds, I would be happy to test these; but I don't think this exists.)

@ilippert
Copy link

@ilippert ilippert commented Mar 17, 2021

JabRef 5.3--2021-03-15--b068ce7
Linux 5.10.22-200.fc33.x86_64 amd64
Java 15.0.2
JavaFX 16+8

have not done anything with JabRef for a few minutes, and it uses 50% of CPU.
happens regularly that JabRef uses up to 100% and then crashes.

@ilippert
Copy link

@ilippert ilippert commented Mar 20, 2021

JabRef 5.3--2021-03-19--049acb9
Linux 5.11.7-200.fc33.x86_64 amd64
Java 15.0.2
JavaFX 16+8

I am sorry to say that JabRef over the last versions reliably crashes and often crashes the system, requiring a cold restart of the computer.

@Ali96kz
Copy link
Contributor

@Ali96kz Ali96kz commented Mar 29, 2021

@ilippert could you provide your .bib file? I will try to investigate it

@Ali96kz
Copy link
Contributor

@Ali96kz Ali96kz commented Mar 30, 2021

Could we test it with that fix #7486

@ilippert
Copy link

@ilippert ilippert commented Mar 30, 2021

JabRef 5.3--2021-03-29--2948e6d
Linux 5.11.10-200.fc33.x86_64 amd64
Java 15.0.2
JavaFX 16+8

Over the last two days I experienced no issues.

@Ali96kz
Copy link
Contributor

@Ali96kz Ali96kz commented Mar 31, 2021

@AEgit Could you test it with that fix #7486, please don't forget to make backups

@AEgit
Copy link
Author

@AEgit AEgit commented Mar 31, 2021

JabRef 5.3--2021-03-29--2948e6d
Windows 10 10.0 amd64
Java 14.0.2
JavaFX 16+8

The issue mentioned in #5071 (comment) persists.

@ilippert
Copy link

@ilippert ilippert commented Jun 17, 2022

JabRef 5.7--2022-06-12--e3b2ab2
Linux 5.17.13-300.fc36.x86_64 amd64
Java 18.0.1
JavaFX unknown

I am quite happy with the performance, however, when typing into fields in the entry editor, the process is often far too slow in actually accepting the input and showing it in the field.

@ThiloteE
Copy link
Collaborator

@ThiloteE ThiloteE commented Jun 17, 2022

meta-issue: #8906

@ThiloteE
Copy link
Collaborator

@ThiloteE ThiloteE commented Jun 17, 2022

JabRef 5.7--2022-06-15--cb5fe60
Linux 5.4.0-120-generic amd64
Java 18.0.1
JavaFX unknown

Tried to reproduce #5071 (comment)

Took me ca. 1-4 minutes to even select 7360 entries from my 100 000 entries database (15,5 mb) with CTRL+Shift+PageUp. This was a lot faster than CTRL+Shift+Up by the way. I don't want to know how long it will take to select 7000 entries with CTRL+Shift+Up....

Then i tried to delete 7360 entries: Used my stop watch to count: 1 hour, 37 minutes ... + X. Did a force close, because I don't want this PC to run at max capacity for hours. Just to delete a simple text in a text-file this seems a little bit over the top.

CPU was pretty high. RAM was normal and stable.
grafik

This was done with an old laptop from 2013: Aspire E13 (ES1-311-P87D), the HDD was replaced with a SSD at one point.

@tobiasdiez tobiasdiez added this to the v5.7 milestone Jun 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Bugs
  
High priority
Development

No branches or pull requests