Potential Memory Leak

[DarkGuardsman]

I've been profiling the server the last few days and have noticed an increase in ram. A few times I've noticed that your BlockPosition class has a massive amount of instances in the ram. At a few points it was consuming 34% of 2GB of ram. This could be a potential memory leak that is being cleaned up by the GC. I'm not sure to the cause but I suspect that something is causing the O2 System to repeat looping. It might be useful to add a delay/queue on repathing when areas change. As this would prevent extra data from being generated per tick. As useful to note watching just the BlockPosition it seems to grow by 48K instances per refresh of the GUI(potentially 1/2 second). This is cleaned up quickly and very rarely spikes up to what is shown in the picture.

[DarkGuardsman]

In theory looking at a few people's bases this could be related to the change from radius to volume. As a few people's bases are exposed to space while still running an O2 vent. Removing the exposer to space slows the ram growth a little, but might be unrelated. I'll experiment more and see if I can get better data.

Simple solution would be to implement a maxium radius again. This way the pathfinder does eventually stop running at points where volume would not be able to reach. Potentially 150m would be a good start, as well add configs to allow limits.

[zmaster587]

It takes a lot of memory to store enough positions for (4/3)_PI_r^3. The lists in question are cleared when an atmosphere cannot be maintained and stored otherwise. This and processing time were to two main reasons I was using a radius based system.

[DarkGuardsman]

You were not forced to switch but requested... but your right it does take a lot of memory for the positions using the volume equation. If my math is right 1.3M per 100 raidus area, which sounds about right. Either way, we need to optimize somewhere to improve the performance. Sorry if this is bugging you I'm just getting frustrated with DragonLords poorly designed modpack. It really shouldn't be eating 2GB with only one person online. Especially considering I disabled all chunkloaders....

I'll see if I can think of something we can try... first though is to use Cube objects for large rect shaped rooms to cut down on pos data. What are your thoughts?

[zmaster587]

Oct tree would take time to implement but is doable. On Jun 23, 2016 2:13 AM, "Robert WC Seifert" notifications@github.com wrote:

You were not forced to switch but requested... but your right it does take a lot of memory for the positions using the volume equation. If my math is right 1.3M per 100 raidus area, which sounds about right. Either way, we need to optimize somewhere to improve the performance. Sorry if this is bugging you I'm just getting frustrated with DragonLords poorly designed modpack. It really shouldn't be eating 2GB with only one person online. Especially considering I disabled all chunkloaders....

I'll see if I can think of something we can try... first though is to use Cube objects for large rect shaped rooms to cut down on pos data. What are your thoughts?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zmaster587/AdvancedRocketry/issues/146#issuecomment-227959353, or mute the thread https://github.com/notifications/unsubscribe/ADX3LQ5lvBT0wTdvwAadjbxVTW4rbEw7ks5qOiQdgaJpZM4I8NT- .

[DarkGuardsman]

Not sure an Oct tree will work, I do have another solution taken right from MC's early days. Instead of storing data with a 3D position object. Make an array per chunk that stores a boolean or byte representing the O2 at the location. This should cut down the amount of memory needed by a massive amount. As with a boolean you are only using a byte per location. Instead of 14 bytes per location. If you use a byte then you can cut this down the boolean by a factor of 8.

[Scarlet-Phonavis]

Noobish question, But how did you profile ram like that? I heard it was rather difficult yet that actually has a decent layout.

[zmaster587]

The software in use in the screenshot is visualvm, and yes, RAM profiling is a pain in the butt... It can be used to create memory dumps that can be fed into other programs like memory analyzer and exmined later as well

[DarkGuardsman]

You also need some understanding of how the programming language works(mainly for size of data objects). This way you can predict how much memory each object is using, for example, one of my Vectors in VE uses 32 bytes -> (3 doubles * 8 bytes) + 8 byte class reference. Which is just a rough estimate as there could be more memory usage depending on design.

http://stackoverflow.com/questions/258120/what-is-the-memory-consumption-of-an-object-in-java

[DarkGuardsman]

@zmaster587 I was just reading over how d-ary heaps work and I have an idea to help reduce the memory usage.

After calculating the O2 bubble convert it to an array, or matrix. This allows you to keep the complex logic for the pathfinder. However, you can then cut your memory usage down by a good bit. As you will not need to store 3 ints for each location.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Is this still an issue? If yes please comment that it still is.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Is this still an issue? If yes please comment that it still is.

[voidsong-dragonfly]

I sure haven't fixed this yet. Bugger off stalebot

[voidsong-dragonfly]

Unlikely to ever see improvement, so closing this.