console.log may be causing a very small memory leak about espruino HOT 4 CLOSED

Hi,

What you're seeing isn't a leak but is just the way Espruino works. Espruino contains a bunch of functions/methods but it can't keep those in a symbol table in RAM all the time because it'd use up memory.

Normally you access something from this list of functions in flash, it's momentarily in RAM, but then it's freed. But when you access something that's a member of something else, that first symbol table entry gets loaded into RAM. In this case what you're seeing is twofold:

• process gets loaded into RAM, when checking the memory
• console gets loaded into RAM, when printing

>process.memory().usage
=290
>process.memory().usage
=292 <----------------- here
>process.memory().usage
=292
>console.log("foo");
foo
=undefined
>process.memory().usage
=295  <-------------- console defined now
>console.log("foo");
foo
=undefined
>process.memory().usage
=295

You can set console to undefined as you note, but actually you've still got a variable called console which is set to undefined (so one var). You could remove it with delete completely and free the memory though (although this is kindof non-standard).

I'm happy to add a note about this behaviour as yes, it can be a bit confusing. Where exactly would you have expected to see info on this? In Testing Afterwards on https://www.espruino.com/Bangle.js+Fast+Load ?

from espruino.

Hi @gfwilliams, I had a feeling that's what was happening :)

Since this is expected behavior, I think there should be a section underneath "Other libraries", maybe called "Other symbols/builtins", which explains these expectations. I think it would also be best to show examples of how to determine if this is happening in your own app.

For context, I am working on a fork of Anton Clock and wanted to make sure I didn't cause any memory leaks (while allowing Fast Loading). Turns out that Anton Clock has (what appears to be) the same memory "leak" that I do. The supposed leak is much larger than these 3 blocks we are talking about above, and I am confident that it doesn't have anything to do with console specifically, but it leaves me questioning. What I really need answered by that page is: how can I be positive that my app isn't leaking memory, and that any leftovers are expected? Checking the module size with E.getSizeOf(global["\xff"].modules) is a good example of the kind of procedure I would want if I was trying to find out whether I have an unexpected memory leak at all. I'm still not sure if my app (or Anton Clock) actually is leaking memory unexpectedly, or if this is all well-defined behavior.

In conclusion, it would greatly benefit devs like me if any additional known caveats to the debugging procedures in the Fast Load instructions were documented there clearly, with concrete steps that will prove whether you have an unexpected memory leak (since right now, a lot of the phrasing on the page leaves you feeling uncertain).

from espruino.

Also, follow up question: can I still take advantage of Fast Load if I call Bangle.setUI() twice in my app? The first one shows the watchface, and the second one shows a different "screen" of the watch. Unfortunately, when the second one is called, it runs the remove function I provided in the first one, which should clean everything up, which means that some resources are no longer available. So it seems like you can't have a clock that calls setUI() more than once and allows for Fast Load. Is that correct?

from espruino.

Ok, cool - I'll add something.

The easy way to check for leaks (which I'll document) is to run your app more than once by repeatedly flicking between the loader and the clock. After the first time a few things (like console) would be allocated, and maybe the launcher would do something too, but after you've done it a few times you shouldn't be seeing the memory usage rise any more.

can I still take advantage of Fast Load if I call Bangle.setUI() twice in my app?

Yes - so you're right that remove is called and that should remove everything global, but you don't have to worry about 'local' variables (eg. defined with let inside a block {}):

{
  let myVariable = { ... };
  let myVariable2 = { ... };

  function changeToScreen1() {
    Bangle.setUI(...);
  }

  function changeToScreen2() {
    Bangle.setUI(...);
  }

  changeToScreen1();  
}

Anything inside that block can use myVariable, and you don't have to delete it when remove is called. You can swap between different setUI and remove will be called and should clear up, but you don't have to worry about myVariable since as long as no function defined in that scope it is used by Espruino after you've cleared up, it will be freed automatically.

from espruino.