Memory Management Issue - Wick Editor Desktop for Windows

PARABÉNS PELA ÓTIMA FERRAMENTA! E CLARO PELA VERSÃO DESKTOP!!! Minha conecção é muito instavel…agora vou poder me aprofundar e aproveitar melhor a sua ÓTIMA FERRAMENTA! Grato!!!

translated:
CONGRATULATIONS FOR THE GREAT TOOL! AND CLEAR BY THE DESKTOP VERSION !!! My connection is very unstable… now I will be able to go deeper and make better use of your GREAT TOOL! Thankful!!!

Hello @Gil_Cartunista, welcome to the forum! I think they already have a desktop version coming soon. Glad you like the editor so far!

Olá @Gil_Cartunista, bem vindo ao fórum! Acho que eles já têm uma versão para desktop em breve. Que bom que você gostou do editor até agora!

@Luxapodular, After testing the windows version and play with it a little… here are some performance numbers…

Everything runs faster than within the web version… the Frame Rate is a lot better.

After several tries… There is a memory management issue
Those numbers are not acceptable, since the app (wick game) that I was running is not that heavy

Here is how you could reproduce/observe the problem… Within first play, everything runs smoothly, but then, every time that you hit play in the editor (to play again without closing the editor), these numbers will increase higher and higher. It seems like every time that you hit play, the old things remain in memory somewhere and then, a new memory allocation is happening for the new run… until the point that the editor crashes.

I think this might have to do with the autosave feature, it might be different for the app version and save everything on your computer rather than on the browser…
I use the web version, so I’m not really sure

@Luxapodular might be able to help you or atleast explain why this might be happening

on the topic of the downloadable editor:


which one is for mac?

No, this bug is for the windows version, but I think that both have the same issue.

I download it from the main wickeditor web page, where it says or download beta.

The problem could be in all versions… It will happens if you use clones and instantiate custom objects from classes. Every time you hit play it will create a new instance somewhere in memory without properly erased the previous play.

it takes me to the github page that i screenshotted. i think 1 is for windows and 1 is for mac but i don’t remember.

mac books can run .pkg files

since you have the desktop editor, i want to ask 2 questions about it:

  • does the memory go back to normal when you quit/reopen?
  • does it automatically update versions?

Yes. If you close the editor and reopen it, the memory starts at 300MBs-500MBs.

Yup… this is huge…
image

Wow, 2740 MB! That is really a lot

I noticed that it doesn’t remove the clone from the this.clones array.
clonetest.wick (1.9 KB)

Click the red rectangle to make a clone, and click on the clones to delete them.

@Luxapodular, are you aware of this?

So there is a bit of an issue here as we use Electron to create our desktop version. Electron utilizes Chromium under the hood, which takes up quite a bit of memory. I need to take a look at the way we are hanging onto assets, and check if we have any memory leaks!

@pumpkinhead may have found it, in that clones are not being removed… going to need to work these fixes into 1.19…

1 Like

Your plan is to the editor to remove clones, from the clone array, automatically after call clone.remove(); ?

It is not only that. That is part of the problem… Every time that we hit play in the Editor, it seems that the previous run data is not cleared.

So, I’ve dug into this and I have found two “memory leaks” that should be fixed in 1.19.

The issues stem from the “Object Cache”, our way of keeping track of every Wick Object in a project. We save references to everything in one place, so that copy/pasting, cloning and other copy based operations are done efficiently.

It turns out that these two bugs

  1. Created extra copies of objects when they were created (For instance, when a path was drawn it made 3 copies instead of 1).
  2. When clones were produced during a project, and the project was played and paused, the elements would stay in the Cache!

Hopefully, a few changes I’m making now should get rid of both of these issues, and add a bit of a safety net in case an accidental change is made.

1 Like