Gpt and Snap performance parameters - exhaustive manual needed!

First, your questions are useful because many others will be interested in the answers.

Many of your questions (the possible exception being #3) are in the category of “excercises left for the reader” or the parable “give a person a fish and that person is fed for a day, but teach a person to fish and that person has food for life”. In other words, the answers are less useful than knowing how to work then out for yourself.

Some insight into the gtp command can be gained by just looking at the gpt script. Here are some examples for a Unix (linux or macOS) installation:

$ file gpt
gpt: POSIX shell script, ASCII text executable, with very long lines
$ wc -l gpt
441 gpt

The best documentation is usually the source code, but on Windows, we only have gpt.exe. If you are on Windows, look in the snap-installer unix bin directory. At this stage, it is useful to know a bit of POSIX shell scripting language. In practice, the majority of Unix systems use the bash implementation. There are many introductory tutorials for bash (including languages other than English). I recommend Linux Command. Windows 10 users can activate Windows Subsystem for Linux (WSL) and install any of the available (and free!) Linux distros from the “Store” to get bash in Windows 10.

Once you feel comfortable reading simple shell scripts, you can examine the rather complicated gpt script. You should discover a shell function called read_vmoptions and also the following “very long line”:

$INSTALL4J_JAVA_PREFIX exec "$app_java_home/bin/java" [...]
  $INSTALL4J_ADD_VM_PARAMS [...] "$@"

If you are bit familiar with shell scripts, you can guess the answer to the first question, and devise experiments to check that your guess is correct. In practice, gpt has become very chatty, so it won’t hurt to have it print a bit of extra detail to record values of options you are tweaking.

Question 2. I suspect the appropriate choice for <cache size> depends on your workload and hardware environment, so the answer requires using JRE and host performance monitoring tools and experimentation.

Question 4. If you watched the tutorials, you should have some insights into how Java manages memory. It likes to have ample memory, so for those of us who don’t have ample budgets, I suspect this option gives Java a bit of help for cases where the “proper” fix might be to purchase more RAM. There are many other potential causes for “Memory problems”, so you should also consider Java performance monitoring tools.

Question 5. There is an explanation of what it is meant to do in various online sources, but also have a look at Java Bug Database to find what it has actually done in the past (I just check and found 22 bugs for AggressiveOpts). Many compilers have similar options. Such options give performance improvements, but can also introduce (usually minor) changes in the results that make it harder to compare output on different hardware. One of the key applications I use has consistently given bit-for-bit identical results across Windows and Unix platforms for a test data set over a period approcahing 10 years. The result differ slightly when using aggressive optimizations and the performance gains small.

2 Likes