search

Nelarius / imnodes

A small, dependency-free node editor for dear imgui
MIT License
2.01k stars 244 forks source link

memory leak #53

Closed ahmidou closed 3 years ago

ahmidou commented 4 years ago

While debugging in visual studio, I noticed that after adding a bunch of nodes the memory use would continually grow. I think just adding onw node is doing the same thing, but the behavior is more noticeable with many nodes. I'm not 100% sure, but Intel Inspector says it's coming from here image

SocketByte commented 4 years ago

Same issue here.

skumbananaaa commented 4 years ago

Same issue here

ahmidou commented 4 years ago

I'm not sure if it's a leak or a growth thought.

Nelarius commented 4 years ago

Thanks for the report! I've had rather limited time for imnodes recently, due to crunch at work. But I will try to investigate once I am in front of Visual Studio again.

It should be noted that, ImGui's draw list containers never shrink, so it might be why you're seeing a memory leak:

    // NOTE: _Channels is not resized down, and therefore _Count <= _Channels.size()!
    const int old_channel_count = splitter._Count;

Two draw channels are spawned for each node + a few extra ones for compositing the foreground and background elements. So with large node counts, it probably is a non-trivial amount of memory. However, the size of the Channels vector in splitter shouldn't grow unless the node count is larger than in the previous frame. Are you seeing really excessive/problematic memory usage by imnodes?

skumbananaaa commented 4 years ago

@Nelarius Yes, I'm using just 4 nodes, they all have the same ID every frame and I'm still getting memory leaks. With more nodes, around 10, the memory usage rises quickly, in about 30 seconds it's up above 1 GB.

Nelarius commented 4 years ago

If you want to work around this issue in the meanwhile, there's the tagged 0.3 release you can use. It doesn't have those draw channel changes which seem to be causing the leak (although rendering overlapping nodes, such as the issue raised here https://github.com/Nelarius/imnodes/issues/36 causes problems)

skumbananaaa commented 4 years ago

Yeah, thanks, I'll do that then

ahmidou commented 4 years ago

The thing is as soon as you added a few nodes and just stop doing anything, the memory will continue to grow on and on until you close the app, so it's not just a large memory usuage.

Le ven. 4 sept. 2020 à 02:25, Johann Muszynski notifications@github.com a écrit :

Thanks for the report! I've had rather limited time for imnodes recently, due to crunch at work. But I will try to investigate once I am in front of Visual Studio again.

It should be noted that, ImGui's draw list containers never shrink, so it might be why you're seeing a memory leak:

// NOTE: _Channels is not resized down, and therefore _Count <= _Channels.size()!
const int old_channel_count = splitter._Count;

Two draw channels are spawned for each node + a few extra ones for compositing the foreground and background elements. So with large node counts, it probably is a non-trivial amount of memory. However, the size of the Channels vector in splitter shouldn't grow unless the node count is larger than in the previous frame. Are you seeing really excessive/problematic memory usage by imnodes?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Nelarius/imnodes/issues/53#issuecomment-686940360, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQUJQSZA5FKE5SZF6PWSYLSECB5DANCNFSM4QNVXYQQ .

Nelarius commented 4 years ago

Thanks a lot for the heads-up, guys! I found and fixed a memory leak with the draw channel grow logic: https://github.com/Nelarius/imnodes/commit/0ff25234c4e84e601dd70ebb6a5505b56737c4e9

On my end, the memory usage now seems to stay nicely bounded when not adding new nodes. Maybe you can also give it a try to see if the library is better behaved?