Increasing the JVM heapsize generally improves performance of FirstSpirit as the built-in Berkeley-DB will scale its internal caches accordingly and less read operations are required for instance during long generation tasks or with many concurrent editor sessions working on the system.
Though the 64bit Oracle JVM, which is recommended for FirstSpirit suffers from a "turbo lag" with heapsizes in the range between 32 GByte and 50 GByte. You should avoid this gap, i.e. either set to only 32 GByte or increase from 50 GByte on. Increasing the JVM heapsize to more than 32 GByte and less than 50 GByte even reduces the usable application memory!
The cause for this unexpected behavior is the automatic deactivation of the JVM flag -XX:+UseCompressedOops which is the default for JVM heaps below a size of 32 GByte. You will see a warning in the fs-wrapper.log about this automatic deactivation. This flag enables storing of all 32 bit values, in a compact way so they don't require a full and unneeded 64 bit word in memory. From 32 GByte on this flag cannot be activated.
That means, the Java application, here the FirstSpirit Server, can only store about half the amount of data when this flag is deactivated. Setting the heapsize for instance to 40 GByte will provide FirstSpirit with the same internal storage capacity as setting it to 20 GByte where the memory compaction is enabled.
Only when increasing the heapsize to more than 50 GByte, the application will receive more usable memory than with setting it to 32 GByte. It is not excactly 50% as most application indeed use some 64bit data objects and those cannot be compressed.
For the technical details take a look at https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/
Further information about using large heapsizes with FirstSpirit is given in https://community.e-spirit.com/docs/DOC-1941
