8GB RAM is currently the entry level of modern desktop. I currently have a PC of 64 GB of ram. I like bookmap to take advantage of my RAM pool and make my program snappier.
Thanks.
Increase bookmap ram support of 8Gb to 64Gb and beyond.
-
amberouserous
- Posts: 6
- Joined: Sat Jun 27, 2020 4:09 am
Re: Increase bookmap ram support of 8Gb to 64Gb and beyond.
I have 32G Ram.. and BM sometimes chokes when fast market or resizing windows/view. Woud having a way to have BM utilize different Ram configurations help reduce this? Tx Tom B
-
Svyatoslav
- Site Admin
- Posts: 278
- Joined: Mon Jun 11, 2018 11:44 am
- Has thanked: 2 times
- Been thanked: 31 times
Re: Increase bookmap ram support of 8Gb to 64Gb and beyond.
Hi,
In short: you normally don't need to change the slider. The value selected by default is supposed to be optimal for your system. If you have more than 16GiB of RAM - it will be set to 4GiB, which is a good option for most use cases.
For those who want to know more, let me explain how bookmap uses memory in general:
- There is certain amount of "native" memory usage. That's what our C++ code and some libraries use + some overhead from JVM. It is fixed and is usually pretty low.
- (legacy) .NET VM (.net virtual machine, for C# code) memory usage. Only matters if you use Ninja (deprecated), S5/Gain/OEC (we'll probably redo it in Java soon) or Transact. If you don't - we won't spin up .NET VM, so it does not matter.
- JVM (java virtual machine) heap. That's the slider you see. It sets a hard limit that JVM is not allowed to exceed. Now, it's not as simple as "more is better". First of all, in Java 8 memory allocation is pretty greedy (we are migrating to Java 14 where it might be better, but for 7.1 it was done only on mac; we will revisit this topic when Java 14 will be used on Windows/Linux too, which will probably be done in a version that will follow 7.1), so giving it more memory will often result in java claiming it and holding onto it thus preventing other more efficient uses (other programs, next item in this list). Now, even if you have more memory than you need, there are still downsides to allocating more memory, and it's potential for GC (garbage collection) pauses. While G1 (the GC algorithm we utilize) does try to limit those, it is still possible that having more data will increase pauses in some cases (but don't quote me on that - it was definitely the case with some older GC's, but not sure if G1 is actually affected; I would expect it to be affected in certain less frequent scenarios).
Now, allocating more memory does have it's benefits, of course - specifically every time java has to collect garbage, there is more to collect - it does not have to recheck every object hoping that it maybe became unreferenced and can be reclaimed, making things more efficient (for G1 that's an oversimplification, but illustrates the idea). But returns are diminishing pretty quickly. Allocating something like 2x-3x of what you actually need is probably a point after which you won't be able to measure any meaningful difference.
So, bottom line - our intention is that 4GiB of heap should be enough for nearly all users. 8GiB option is there just in case you want to run some memory-hungry layer1 addon or something - say you trained a large neural network to show some indicator. In other cases - we do not expect increasing allocation past 4GiB to do much in most use cases.
If you see a difference between 4GiB and 8GiB - let me know, and we'll try to investigate. There should be no point in going past 8GiB in current version.
- Memory mapped files. Bookmap stores data on disk (that big Cache folder that you see), but it does not use "normal" files for that. It uses MMF's, which is a way to tell OS "map this file to address space" (sort of to memory), and then work with it like with RAM. Now, OS will automatically dump it to disk and load it from disk when necessary. Nice part is that it also will use free RAM to store those files, but will automatically shift data to disk if other apps need more RAM (usually you'll see up to 90-95% RAM usage in "Performance" tab of task manager when that happens). This speeds recentering up, while not claiming the memory exclusively, as if we'd just store it in RAM.
Recentering performance is dependent on amount of data, mostly. If you don't see a difference between 4 and 8 GIB - then it's mostly on our side to optimize it further. If you do - let me know, we'll investigate why. Because in theory you should not.
In short: you normally don't need to change the slider. The value selected by default is supposed to be optimal for your system. If you have more than 16GiB of RAM - it will be set to 4GiB, which is a good option for most use cases.
For those who want to know more, let me explain how bookmap uses memory in general:
- There is certain amount of "native" memory usage. That's what our C++ code and some libraries use + some overhead from JVM. It is fixed and is usually pretty low.
- (legacy) .NET VM (.net virtual machine, for C# code) memory usage. Only matters if you use Ninja (deprecated), S5/Gain/OEC (we'll probably redo it in Java soon) or Transact. If you don't - we won't spin up .NET VM, so it does not matter.
- JVM (java virtual machine) heap. That's the slider you see. It sets a hard limit that JVM is not allowed to exceed. Now, it's not as simple as "more is better". First of all, in Java 8 memory allocation is pretty greedy (we are migrating to Java 14 where it might be better, but for 7.1 it was done only on mac; we will revisit this topic when Java 14 will be used on Windows/Linux too, which will probably be done in a version that will follow 7.1), so giving it more memory will often result in java claiming it and holding onto it thus preventing other more efficient uses (other programs, next item in this list). Now, even if you have more memory than you need, there are still downsides to allocating more memory, and it's potential for GC (garbage collection) pauses. While G1 (the GC algorithm we utilize) does try to limit those, it is still possible that having more data will increase pauses in some cases (but don't quote me on that - it was definitely the case with some older GC's, but not sure if G1 is actually affected; I would expect it to be affected in certain less frequent scenarios).
Now, allocating more memory does have it's benefits, of course - specifically every time java has to collect garbage, there is more to collect - it does not have to recheck every object hoping that it maybe became unreferenced and can be reclaimed, making things more efficient (for G1 that's an oversimplification, but illustrates the idea). But returns are diminishing pretty quickly. Allocating something like 2x-3x of what you actually need is probably a point after which you won't be able to measure any meaningful difference.
So, bottom line - our intention is that 4GiB of heap should be enough for nearly all users. 8GiB option is there just in case you want to run some memory-hungry layer1 addon or something - say you trained a large neural network to show some indicator. In other cases - we do not expect increasing allocation past 4GiB to do much in most use cases.
If you see a difference between 4GiB and 8GiB - let me know, and we'll try to investigate. There should be no point in going past 8GiB in current version.
- Memory mapped files. Bookmap stores data on disk (that big Cache folder that you see), but it does not use "normal" files for that. It uses MMF's, which is a way to tell OS "map this file to address space" (sort of to memory), and then work with it like with RAM. Now, OS will automatically dump it to disk and load it from disk when necessary. Nice part is that it also will use free RAM to store those files, but will automatically shift data to disk if other apps need more RAM (usually you'll see up to 90-95% RAM usage in "Performance" tab of task manager when that happens). This speeds recentering up, while not claiming the memory exclusively, as if we'd just store it in RAM.
Recentering performance is dependent on amount of data, mostly. If you don't see a difference between 4 and 8 GIB - then it's mostly on our side to optimize it further. If you do - let me know, we'll investigate why. Because in theory you should not.