Possible memory leak when using {{#if}} helper with a reactive variable

[xamfoo]

If I use the {{#if}} helper like this

<template name="list">
  <ul>
    {{#each items}}
      {{#if show}}
        <li class="item">item</li>
      {{/if}}
    {{/each}}
  </ul>
</template>

with show being a reactive variable,

Template.list.helpers({
  items: function () { return Items; },

  show: function () { return Session.get('show'); }
});

changing show seems to cause a memory leak in the browser.

Session.set('show', false);
// wait
Session.set('show', true);

In my testing, doing this repeatedly can increase memory use from 29.3mb to 588mb. There is also a corresponding increase in the number of nodes. (See screenshot of timeline profiler)

Test environment:

• Meteor 1.1.0.2
• Chromium Version 41.0.2272.118 (64-bit) on a Linux box
• Developer tools > Timeline > Click record > GC > Toggle reactive variable multiple times > GC > Click stop

Repo used to produce issue: https://github.com/xamfoo/meteor-issue

[eshell]

what if you wrap {{#if}} around the {{#each}} instead? If you wan't to show or hide all the items individually, you should put the {{if}} first so {{each}} isn't being executed when it doesn't have to be.

<template name="list">
{{#if show}}
  <ul>
    {{#each items}}
        <li class="item">item</li>
    {{/each}}
  </ul>
{{/if}}
</template>

the way your doing it now makes it so even if you don't wanna show items, it still iterates through every item in {{#each}}.

[xamfoo]

I don't think the issue comes from {{#each}} because when I tried removing {{#each}} memory usage still increases.

If you wan't to show or hide all the items individually, you should put the {{if}} first so {{each}} isn't being executed when it doesn't have to be.

I agree. However, we may still want to put the {{#if}} helper inside {{#each}} when

• Checking if the iterated item is inside a white list
• Temporarily hiding some items without regenerating the whole DOM

[glasser]

I ran your reproduction and yes, it absolutely looks like there's a leak there. Another way to see is to (after GCing) take a heap snapshot; I saw a number of HTMLLIElements which was a large multiple of 1000 (and which went up as I clicked more times).

This seems pretty serious!

I'm about to head out for the day; can you try running this on older versions of Meteor to see when this was introduced, if it didn't always exist? Note that before 1.0.4 you can't use onCreated (but the body of that block could just be at top level).

[xamfoo]

can you try running this on older versions of Meteor to see when this was introduced, if it didn't always exist?

This issue seems to exist in Meteor version >= 0.8.3

Seems ok - 0.8.0, 0.8.1, 0.8.2
Issue exists - 0.8.3, 0.9, 1.0.4.1, 1.1.0.2

The code in the repo has been updated to run on older Meteor versions. I ran it like this:

meteor run --release 0.8.3

[glasser]

Thanks for the great reproduction. I tracked down this particular leak and I think it's fixed.

[xamfoo]

That was fast. Thanks!