Open AEgit opened 5 years ago
@AEgit the most recent developement version now includes the latest performance improvements. Could you please check what still needs improvement. Thanks!
@tobiasdiez Due to the issues with the current Windows installer (see https://github.com/JabRef/jabref/issues/5580#issue-520403252) and since the snap package on Linux also does not seem to work yet (see https://github.com/JabRef/jabref/issues/5417) I cannot test the current developer version, I am afraid.
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.
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:
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.
Thanks for the feedback. I'll try to have a look at the remaining performance issues in the next days.
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 (https://github.com/JabRef/jabref/issues/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).
@tobiasdiez related to the add tab threading?
@AEgit We implemented some performance improvements recently. Can you please see if they might have fixed some of the issues you described in https://github.com/JabRef/jabref/issues/5071#issuecomment-554769666. Moreover, it would be good which of the remaining issues are critical, i.e. need to be fixed before we release 5.0. Thanks
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 https://github.com/JabRef/jabref/issues/5071#issuecomment-554769666):
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.
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
Could you all please test with the latest development version? We upgraded to javafx14 which comes with an overall performance improvement. We still have to optimize some bottlenecks, but I personally noticed some performance increases
JabRef 5.1--2020-03-18--99183e1 Windows 10 10.0 amd64 Java 13.0.2
I am afraid, as mentioned previously (https://github.com/JabRef/jabref/issues/5510#issuecomment-590564792; https://github.com/JabRef/jabref/issues/5735#issuecomment-591904187), the performance is actually worse for me - it is so bad, that I cannot use my large database any more for bug testing.
JabRef 5.1--2020-03-18--99183e1 Linux 5.5.8-200.fc31.x86_64 amd64 Java 13.0.2
with approx 10600 entries
in the entry table, when I sort according to a column, the first time I click onto a column header, it can take 15-20 seconds to sort the entries. the second time, sorting in the opposite order, takes only a 3 seconds.
Side comment: For sharing screen recordings, loom was recommended to me. Then, everyone with a web browser can see the videos. (I got comments that some users could not see the videos above)
I would assume that this issue also covers search-as-you-type, where @hankstevens01 and @lc9275 reported that it is very slow:
Thus, I just list it here.
I found some Easter eggs in the code. After eating them JabRef now feels more slim and responsive. In fact, for me all the performance problems mentioned in this issue are fixed now.
@AEgit @ilippert @Codeberg-AsGithubAlternative-buhtz 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.
@koppor @tobiasdiez Is the snap --edge channel now updated on every commit to master?
JabRef 5.1--2020-04-10--d4396ce Linux 5.5.15-200.fc31.x86_64 amd64 Java 14
thanks for the note! this is my experience:
JabRef 5.1--2020-04-10--d4396ce Mac OS X 10.15.4 x86_64 Java 14
Database of 19800 refs
On Sun, Apr 12, 2020 at 10:09 AM Ingmar Lippert notifications@github.com wrote:
JabRef 5.1--2020-04-10--d4396ce Linux 5.5.15-200.fc31.x86_64 amd64 Java 14
thanks for the note! this is my experience:
- sorting my 10600 entry file by title still takes 30 seconds (should be a basic entry table operation).
- after running jabref for about 2 minutes, jabref often hangs, being unresponsive.
- after running for 8 minutes, jabref has memory 1.7gb, virtual memory 91,2 gb, resident memory 1,8gb, shared memory 128mb
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JabRef/jabref/issues/5071#issuecomment-612620760, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVZLPEM7Q2WXNO3VXZKKF3RMHDSDANCNFSM4H2ZP5UA .
--
“Life is a garden, not a road. We enter and exit through the same gate. Wandering, where we go matters less than what we notice.” Dr. Hank Stevens Pronouns: he/his
Director, Ph.D. Program in Ecology, Evolution, and Environmental Biology https://miamioh.edu/cas/academics/programs/eeeb/
Associate Professor (lab website https://blogs.miamioh.edu/stevens-lab/)
Miami University | Department of Biology
433 Hughes Hall
Oxford, OH 45056 O: 513-529-4206 | Hank.Stevens@MiamiOH.edu https://miamioh.edu//miami-tribe-relations/index.html Learn more about Miami Tribe Relations https://miamioh.edu//miami-tribe-relations/index.html
Sorry, the build has failed to upload the files. Please test the version from the run: https://github.com/JabRef/jabref/runs/580559222 (Top right corner, "Artifacts") (Unfortunately the github build system puts all versions for one os together in one archive)
sorry, I am not sure what you mean - I cannot find Artifacts at the linked page. I can find some at https://github.com/JabRef/jabref/actions/runs/76469953 - do you mean those?
@ilippert Yes, sorry, I had apparently linked the wrong run.
Sorry to disappoint ... first attempt to run
"easter egg"? Can you please link the commit where it was removed? Does the "easter egg" will have any consequences for some persons and/or for the quality control process in the JabRef development?
Starting JabRef still cost to much time. But the issue with text entry is ok - for now.
@Codeberg-AsGithubAlternative-buhtz please don't take the word "easter egg" literally. It was meant as issue I the JabRef code. We are working hard to get students on board at JabRef development. See https://devdocs.jabref.org/teaching for details. At the linked page https://devdocs.jabref.org/getting-into-the-code/development-strategy you see that we take quality serious. Please don't fear that we "play around" with JabRef.
JabRef 5.1--2020-04-12--771af5d Windows 10 10.0 amd64 Java 14
@tobiasdiez : Thank you very much! This is, indeed, a nice "easter egg". Many of the previous performance issues have now either disappeared or are much less pronounced, than they were before.
I will list here the issues that appear to remain, mainly based on comment https://github.com/JabRef/jabref/issues/5071#issuecomment-575912921:
Additionally:
These changes are a major step forward! Well done. I reckon once these minor issues are solved and when the floating mode is re-implemented (https://github.com/JabRef/jabref/issues/4237) I can finally move from version 3.8.2 to version 5.1 for my working environment.
@ilippert @AEgit thanks for the feedback.
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
JabRef 5.1--2020-05-04--b5599c9 Windows 10 10.0 amd64 Java 14.0.1
Can confirm the issue reported by @ilippert (https://github.com/JabRef/jabref/issues/5071#issuecomment-624058022). 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.
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.
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.
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 ... https://github.com/JabRef/jabref/issues/6559
@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: https://github.com/JabRef/jabref/issues/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.
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"?
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.
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 ;)
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.
Thanks for the report. Do you remember the last version were you didn't experienced these problem?
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.)
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.
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.
@ilippert could you provide your .bib
file? I will try to investigate it
Could we test it with that fix #7486
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.
@AEgit Could you test it with that fix #7486, please don't forget to make backups
JabRef 5.3--2021-03-29--2948e6d Windows 10 10.0 amd64 Java 14.0.2 JavaFX 16+8
The issue mentioned in https://github.com/JabRef/jabref/issues/5071#issuecomment-624073216 persists.
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,
meta-issue: #8906
JabRef 5.7--2022-06-15--cb5fe60 Linux 5.4.0-120-generic amd64 Java 18.0.1 JavaFX unknown
Tried to reproduce https://github.com/JabRef/jabref/issues/5071#issuecomment-624073216
Took me ca. 1-4 minutes to even select 7360 entries from my 100 000 entries database (15,5 mb) with Shift+PageUp. This was a lot faster than 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.
This was done with an old laptop from 2013: Aspire E13 (ES1-311-P87D), the HDD was replaced with a SSD at one point. The CPU is a Intel Pentium N3540, which is designed for long battery life and consequently has weak benchmarking results: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+N3540+%40+2.16GHz&id=2408
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 (https://github.com/JabRef/jabref/issues/4430#issuecomment-504119679), 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:
https://github.com/JabRef/jabref/issues/4430 https://github.com/JabRef/jabref/issues/4756 https://github.com/JabRef/jabref/issues/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.
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.
Comparison of JabRef search feature: 3.8.2: https://app.box.com/s/fgr84sgpsz6dscbnku91m5o2hhbf6rwt 5.0: https://app.box.com/s/fxwcska8dm5rlilv6a9mqswelkrqkh0t
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).