[SOLVED] What does "Tracker._FViewRunFlush -- splitting after 3ms, 146 pending computations" mean?

I’m seeing a whole ton of outputs like this in my console:

Tracker._FViewRunFlush -- splitting after 3ms, 146 pending computations

This is something specific to famous-views. We override Tracker’s implicit flush loop to prevent a long running flush from blocking animation frames. If we see we’re taking too long, we pause, let Famous draw the next frame, and then carry on where we left off.

That message is actually not shown in the stable release, it was just turned back on again for the early work with Engine. Happy to report it’s working great though so this will disappear again and only more interesting messages like:

  debug:  [famous-views]  The following computation took 24ms to complete: function viewAutorun(c) wikiRender:materialize

will be shown by default, as per the Reactivity section of http://famous-views.meteor.com/performance (they can be turned off and fine-tuned too, to help you track down any potential slow downs in your Meteor level code).

However, if you’re seeing the original message “tons” of times, it’s possible you’re unintentionally using more reactivity than you really want. If you’re not doing anything particularly complicated, take a look in your code about which deps would be invalidated on a particular change, and what those functions might invalidate in turn, etc. 146 pending computations after already running for 3ms seems like a lot.

The great news though is that if you’re seeing this so much but didn’t notice any problems with your animations, you’ve seen just how well this technique works :>

You can also adjust the debug level per the README with:

Package['jag:pince'].Logger.setLevel('famous-views', 'info');

Levels are: trace, debug, info, warn, error
Default is “debug” for early releases.

Oh, of course, I should’ve noticed the “FView” in “_FViewRunFlush”… So you were the perfect person to ask. You’re quite the expert on that reactive stuff. :smile:

it’s possible you’re unintentionally using more reactivity than you really want

That’s the exact feeling that I had (I’m taking over a code base, it’s not my fault. :laughing:).

The great news though is that if you’re seeing this so much but didn’t notice any problems with your animations, you’ve seen just how well this technique works

Not yet actually, these were happening when trying out this traditional jQueryUI drag/drop stuff. I’m looking forward to seeing how it fairs with Famous! I’m gonna try that recursive template idea. Let’s continue on http://forums.famous-views.org. :smiley:

1 Like