Tracker profiler

help
1

Recently I’ve puzzled myself with profiling functions and reactive variables in my app.
And as simple as Tracker may be - there’s no built-in functionality for determining what caused a rearun of reactive computation.
What’ the best way to log all changes in reactive vars and such in a Blaze app?

2

Take a look at the tracker manual for a deeper understanding of tracker’s mechanics.

And perhaps sprinkle some Tracker.afterFlush callbacks here and there to console.log what’s going on.

3

I think it’s very hard to debug Tracker overall because there are like a 1000 (or thousands) of them being spun up by every little thing.

If what you want is to avoid re-rendering issues, you may want a Chrome extension that helps observe changes to the DOM.

I believe this is a good one (I have not used it)

Another key thing is to avoid using objects with-in Reactive Var / Reactive Dict because Meteor currently cannot observe which part of the object changed, so it’ll update everything.

4

Interesting…

I’m on Meteor 1.3.5.1 and for a long time I’ve ran my production deployment with just MUP without issues. I had a requirement to add SSL to my site so over the weekend, so I added nginx and SSL. The app almost immediately starting reloading constantly. I read the issue was solved by removing caching from the config file.

if ($uri != '/') {
  expires 30d;
}

That worked.

But now to the point… I then noticed while debugging another issue, at least one of my tracker methods that uses Meteor.userId() and a few Session variables is constantly triggering when I don’t think it should. And since I wrote this tracker recently, I do not remember this happening before. Is there a way to find out, when one has a few Session variables inside a Tracker method, what exactly is triggering it to run? And could there be a connection between that tracker function cycling and setting up the nginx?

5

You can use console.trace() sometimes to… ehm, trace the origin of tracker rerun.
Dont know about nginx though

1 Like
6

I’m mostly interested not in dom changes but in what caused the underlying template helpers to change.

7

How will that help? I need to log all reactive objects’ mutations and what caused them.

8

Try adding the following:

  let originalCompute = Tracker.Computation.prototype._compute;
  Tracker.Computation.prototype._compute = function() {
    originalCompute.call(this);
    this._callers = [];
  };

  let originalInvalidate = Tracker.Computation.prototype.invalidate;
  Tracker.Computation.prototype.invalidate = function() {

    if (!this._callers) {
      this._callers = [];
    }

    let e = new Error('dummy');
    this._callers.push(e.stack);

    originalInvalidate.call(this);
  };

  Tracker.why = function() {
    let comp = Tracker.currentComputation;
    if (!comp) {
      console.log('Not in a computation');
      return;
    }

    if (comp.firstRun) {
      console.log('This is the first time this computation is being run');
      return;
    }

    return comp._callers
      .map(stack =>
        stack.split("\n").slice(2).find(line => !line.includes('packages/tracker.js') && !line.includes('packages/reactive-var.js') ).split(' ')[5]
      );
  };

Then breakpoint in the autorun you want to debug and type Tracker.why(). Definitely don’t run this all the time; it causes a very large slowdown.

4 Likes