Joel and anyone else who can contribute, maybe you could answer some general memory questions for me while waiting for a log file. I’ve made many vmods over the years, and I’ve never had a memory issue. But if I did, I think I’d approach it from two directions. One, of course, is to allocate more memory. The other is to reduce my module’s demand for memory.
The only things I see in a module that would gobble up memory are the image files. Is that correct? Suppose my main map occupies 1mb on my disk. I doubt the 1mb translates into memory, so what characteristics of a file translate into memory demand? Dots per inch? And if I know those characteristics, shouldn’t I be able to use them to estimate how much memory that file will need?
Another thing that puzzles me about this guy’s problem is he doesn’t see an error until he is ready to save or close the session. I would think the error should happen when Vassal first tries to open and load the image into memory, but that’s not what seems to be happening. I don’t understand what’s going on here.
Image file size doesn’t matter. Image DPI doesn’t matter. The only thing that matters for the memory usage of a particular image is the dimensions of the image.
When tiling an image, the whole thing needs to fit into memory when decoded. When using a module, the amount of memory images will use collectively is whatever memory the JVM has which isn’t being used by anything else, because images are stored in a cache where entries are dropped when the memory is required for something outside the cache or to make space for newer entries. If you want good rendering performance, you want most of the images which are being rendered to be in the cache already; if too many have to be loaded from disk on each draw, you’ll get flickering or delayed drawing.
Running out of memory when a module is open typically isn’t caused by images. Running out of memory when using a module can happen due to very deep trait stacks. Running out of memory when saving can happen because the serialization format for game state has a fundamental design flaw that makes it far, far larger than it should be.
I’ve always had similar problems (I’ve been using Vassal since 2010) and I still do. Since I’m just a gamer and not a computer expert, I’ll gladly leave the technical considerations to the experts.
All I can report is my personal experience over the past decade, nothing more.
I’ve always wondered what the real cause of excessive memory consumption and other similar problems is, such as having 4 MB log files with moderately large maps and a negligible number of units (a few hundred at most), but using numerous prototypes and variables of all kinds, and having to wait minutes for GKC to do its job.
I’ve searched, in vain, on the forum and, subsequently, through specific requests on these topics, for a solution to these problems.
I’ve currently reserved 32 GB of memory (out of 64) and can at least save the log file, but the program’s slowness, which I don’t think can be attributed to hardware deficiencies, has remained the same.
In my opinion, attempting to use this excellent program beyond its capabilities can only lead to these problems.
Perhaps the legendary yet elusive version 4 will solve many of these problems. Too bad, having recently turned 70, I may never see it…
Without naming the module(s) you have these experiences with, no one can do much but speculate. Giant trait stacks are the chief cause of slow GKC execution. The size of maps will have nothing to do with file sizes of saved games or logfiles.
Image file size doesn’t matter. Image DPI doesn’t matter. The only thing that matters for the memory usage of a particular image is the dimensions of the image.
I need a little more to understand this. Suppose I have a map image that is 10” by 10”. That’s one way to express the dimensions. Suppose the image is a png, and it’s 100 pixels per inch. That means the dimensions are 1000 by 1000 pixels. But suppose it’s 500 dpi; then it’s 5000 x 5000. I don’t understand how dimensions matter but not dpi. I’m probably missing something obvious, but I don’t see why dpi doesn’t matter since it can affect dimensions.
Is it possible to estimate how much memory my map image needs? And if you had a memory problem, how would you attack it besides increasing memory allotment?
You said there is a fundamental design flaw when vassal serializes the game state. Is that a java flaw or a vassal one? Can Vassal tell me how much memory it thinks it needs?
Raster images are stored as pixels. There might be DPI or original size in some length units stored as metadata, but they’re irrelevant. They do not affect the dimensions in pixels. All that matters for loading such an image is its dimensions in pixels.
A complete decoded image in memory will use 4wh bytes, where w is the width and h is the height in pixels. The only time you will have a complete decoded map image in memory is during tiling.
That depends on what’s using the memory. Someone would need to look at the module to recommend anything.
It’s a design flaw in the serialization format used by Vassal, which goes back to the very beginning. Some trait data grows quadratically with the depth of the trait stack. It’s not fixable without entirely rewriting the way game data is stored.
No. If it could, we would use that for sizing the heap.
DPI is relevant to printing on physical media. Digital images have no DPI, whatever metadata or image software might represent. Explainer video(just picked one of countless examples)
At least, once you have determined what is a reasonable value, you can now - since Vassal 3.7.16 - specify a minimum JVM Max Heap within the module Global Options. If a value entered here is greater than the user preference, the user preference is updated and the module advises the user accordingly.
As previously stated. No errorlog. So nothing for you to do wrt to that matter. Also, unlikely to get an errorlog unless I deliberately reduce the JVM size. Not happening.
Agreed, but there is no way to fix this in V3, nor would I do further work on V3 even if there were. V4 will not behave this way.
Really, that is surprising. Clicking on the X or selecting file/quit may continue to fail to do just that? Wow, that is an issue.
I have met unresponsive software quite a few times over the many years I’ve used a PC, using win task manger has enabled me to close those miscreants. But using software that is still ‘active’, as in you can still click on the X or file/exit, get a popup window (with in this case OOM, etc) is not exactly unresponsive. More like ‘I’ respond but you cannot do anything more with my response apart from change preferences, continue editing the module, etc but “why bother because the software is not going to do anything further” - apart from just continue to post OOM error and cycle back to seeming continuance - ad infinitem. What a parlous state that is.