Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

"Private" isolated scope #10140

Closed
Closed

Description

@kostat

Directives with isolated scope are usually not interested in $digest cycles unless one of the scope expressions they specified has changed. Ability to control it would significantly improve performance.

Activity

  1. Narretz commented on Nov 20, 2014

    @Narretz
    Contributor

    I think this is the same as #5830
    However, a similar (the same?) idea called "localApply" was tested here #8055 and found to be too difficult to implement.

  2. kostat commented on Nov 20, 2014

    @kostat
    Author

    @Narretz: the issue you mention is almost the opposite of my suggestion! I'm talking about skipping a scope subtree during $digest, while #5830 proposes to limit $apply.

    The implementation is also relatively trivial:

    • Have a special collection of $$digestWatchers.
    • These watchers would behave exactly same as "normal" watchers except that if all of them are not dirty, the loop would not run the "normal" watchers neither for that scope, nor for its children.
    • "local" (internal) $applies will check the same after an internal $digest, whether any of 2-way $$digestWatchers is dirty and call the root's $apply
    • [I omit detailing of "private" child scopes $apply changes, but they are fairly trivial too]
    • During DDO $compilation $$digestWatchers will be initialized from the DDO's scope definition.

    If I had an assertion, that the contribution would be accepted provided it passes tests/quality standards, I can do it myself (I'm a large mono contributor in the past).

    P.S. I'd like also ask you to remove the resolution label.

  3. added this to the Ice Box milestone on Nov 21, 2014
  4. Narretz commented on Nov 21, 2014

    @Narretz
    Contributor

    I've reopened it, but I can't evaluate the feasability of the change. In general, a PR as a more substantial starting point is always good, and perf improvements are always welcome.

  5. kostat commented on Nov 26, 2014

    @kostat
    Author

    Created a relevant PR: #10221. My tests show reduce of watcher check by x3-x10.

    • There are additional optimizations that can be done in this area. I'll add more PRs when we progress with this one
  6. Narretz commented on Jan 22, 2016

    @Narretz
    Contributor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions