Speed up JabRef-3.7.jar?

My experience with Java is less and extrem old.
I use the JabRef-3.0.jar file from your website on Debian unstable.
My netbook is old, too. Because of that it is slow. JabRef is near til unusable because of that.

Is there a way to speed that up?
Maybe can I compile the code and run it native without using the java-byte-code interpreter?

I tried to use GCJ to compile.

$ gcj JabRef-3.7.jar -v
Using built-in specs.
Reading specs from /usr/lib/gcc/i686-linux-gnu/6/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.1-5' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc=auto --enable-targets=all --enable-multiarch --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 6.2.1 20161124 (Debian 6.2.1-5) 
COLLECT_GCC_OPTIONS='-v' '-fbootclasspath=./:/usr/share/java/libgcj-6.jar' '-g1' '-specs=libgcj.spec' '-shared-libgcc' '-mtune=generic' '-march=i686'
COLLECT_GCC_OPTIONS='-v' '-fbootclasspath=./:/usr/share/java/libgcj-6.jar' '-g1' '-specs=libgcj.spec' '-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/6/jc1 JabRef-3.7.jar -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase JabRef-3.7.jar -mtune=generic -march=i686 -auxbase JabRef-3.7 -g1 -version -fbootclasspath=./:/usr/share/java/libgcj-6.jar -faux-classpath /tmp/cc9UzfH2.zip -o /tmp/ccB3QnPq.s
GNU Java (Debian 6.2.1-5) version 6.2.1 20161124 (i686-linux-gnu)
	compiled by GNU C version 6.2.1 20161124, GMP version 6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Java (Debian 6.2.1-5) version 6.2.1 20161124 (i686-linux-gnu)
	compiled by GNU C version 6.2.1 20161124, GMP version 6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Class path starts here:
    /tmp/cc9UzfH2.zip/ (zip)
    ./ (system)
    /usr/share/java/libgcj-6.jar/ (system) (zip)
In file included from net/sf/jabref/logic/importer/fileformat/mods/AccessConditionDefinition.java:503:0,
                 from net/sf/jabref/logic/importer/fileformat/mods/AbstractDefinition.java:425,
                 from net/sf/jabref/logic/importer/fileformat/mods/NameDefinition.java:758,
                 from net/sf/jabref/logic/importer/fileformat/mods/DateDefinition.java:213,
                 from net/sf/jabref/logic/importer/fileformat/mods/StringPlusLanguagePlusSupplied.java:106,
                 from net/sf/jabref/logic/importer/fileformat/mods/ExtentDefinition.java:213,
                 from net/sf/jabref/logic/importer/fileformat/mods/RecordInfoDefinition.java:290,
                 from net/sf/jabref/logic/importer/fileformat/mods/ExtensionDefinition.java:142,
                 from net/sf/jabref/logic/importer/fileformat/mods/ItemIdentifierDefinition.java:65,
                 from net/sf/jabref/logic/importer/fileformat/mods/EnumerationAndChronologyDefinition.java:104,
                 from net/sf/jabref/logic/importer/fileformat/mods/FormDefinition.java:96,
                 from net/sf/jabref/logic/importer/fileformat/mods/CopyInformationDefinition.java:313,
                 from net/sf/jabref/logic/importer/fileformat/mods/CopyInformationDefinition.java:610,
                 from net/sf/jabref/logic/importer/fileformat/mods/HoldingSimpleDefinition.java:104,
                 from net/sf/jabref/logic/importer/fileformat/mods/UrlDefinition.java:217,
                 from net/sf/jabref/logic/importer/fileformat/mods/StringPlusLanguagePlusAuthority.java:161,
                 from net/sf/jabref/logic/importer/fileformat/mods/PhysicalLocationDefinition.java:281,
                 from net/sf/jabref/logic/importer/fileformat/mods/LocationDefinition.java:483,
                 from net/sf/jabref/logic/importer/fileformat/mods/HierarchicalGeographicDefinition.java:225,
                 from net/sf/jabref/logic/importer/fileformat/mods/StringPlusLanguage.java:223,
                 from net/sf/jabref/logic/importer/fileformat/mods/IdentifierDefinition.java:180,
                 from net/sf/jabref/logic/importer/fileformat/mods/OriginInfoDefinition.java:361,
                 from net/sf/jabref/logic/importer/fileformat/mods/PartDefinition.java:430,
                 from net/sf/jabref/logic/importer/fileformat/mods/RelatedItemDefinition.java:545,
                 from net/sf/jabref/logic/importer/fileformat/mods/ModsDefinition.java:378,
                 from net/sf/jabref/logic/importer/fileformat/mods/ModsCollectionDefinition.java:104,
                 from net/sf/jabref/logic/importer/fileformat/mods/package-info.java:223,
                 from <built-in>:127:
net/sf/jabref/logic/importer/fileformat/mods/AreaDefinition.java:67:0: internal compiler error: Speicherzugriffsfehler

Which java version do you use? OracleJRE or the OpenJDK-jre? If you didn’t try Oracle, we recommend you to follow http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html

Do you experience the same speed issues when using javref-2.10 from debian/stable?

If all that doesn’t help, I think, we have to regret and ask you to try some other BibTeX program. Some are listed at https://github.com/JabRef/jabref/wiki/Alternatives. We heared that http://home.gna.org/kbibtex/ is used by some persons.

I don’t see JabRef as a “BibTeX program”. :wink: It is a literature managment software and work well for a lot of my scientific buddies. :slight_smile: So, no alternatives.

Oracle Java is maleware itself. For security reason I can’t install it.

And beside of it I don’t think another Java version would speed up here. The point is that my machine is very old and to slow.

The question was about is it possible to real compile JabRef for my machine. This would speed it up. I know about the bytecode concept but never used Java. So I don’t know if it is possible with JabRef and if it is possible.

Are you aware that the OpenJDK is also mainly produced by Oracle? So, if you want to avoid Oracle, you should rather uninstall Java as a whole. Having said that, OracleJDK is usually more stable, also according to my personal experience, which is why I recommend it in place of OpenJDK.

Java code is compiled to bytecode, which is what we ship and what you install. Once it is on your machine, your Java VM executes the bytecode and, if it decides that something is worth optimizing, translates the bytecode to machine code for your machine on demand. For what it’s worth, OracleJDK is probably much better at deciding on this and also at producing more optimized machine code. Unlike with a C program, you do not compile JabRef for your machine. Your virtual machine does that for you.

I understand that the jdk compiles the code on demand.
Exactly that is what I want to stop.

I want to precompile it only one time. Is that possible?

Well, it seems that at least hotspot had an option for that. Adding -Xcomp as command line arg did the precompilation according to the linked stackoverflow post. However, that is a non-standard command line argument, and whatever VM you are using might differ. You should probably have a look at the documentation of the VM that you use.

Having clarified the “compile Java” thing, is there something we can do to speed JabRef up? What kind of operations are slow for you? For example, we have benchmarks for reading and writing bib files (and also for other operations) and try to improve on these aspects. Maybe we miss something.

Moreover, some users reported that disabling “Groups -> Settings -> Show number of entries contained in groups” make JabRef more fluent (especially with a large number of groups).

Thanks for asking. But it is to much work with less effect. It is a 2nd generation netbook with a single core atom CPU. So you see THIS is the reason. :wink:

I will check how I can work with 100s of categories and 10000 of items.

Some other suggestions which might speed up JabRef a bit:

  • Disable the autocompletion at the Preferences -> Entry Editor settings
  • Hide unused “Special fields” (Preferences -> Entry Table Columns)
  • Deactivate name adjustments in table (Preferences -> Entry Table -> Select “Show names unchanged”)
  • Disable “Fit Table horizontally on screen” (Preferences -> Entry Table)

I have not tested or even measured the impact of disabling this settings - but they should improve the situation at least slightly :wink: