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

chore(Scope): short-circuit after dirty-checking last dirty watcher #5287

Closed
wants to merge 1 commit into from

Conversation

IgorMinar
Copy link
Contributor

Stop dirty-checking during $digest after the last dirty watcher has been re-checked.
This prevents unneeded re-checking of the remaining watchers (They were already checked in the previous iteration), bringing a substantial performance improvement to the average case run time of $digest.

Closes #5272

Stop dirty-checking during $digest after the last dirty watcher has been re-checked.
This prevents unneeded re-checking of the remaining watchers (They were already checked in the previous iteration), bringing a substantial performance improvement to the average case run time of $digest.

Closes angular#5272
@mary-poppins
Copy link

Thanks for the PR!

  • Contributor signed CLA now or in the past
    • If you just signed, leave a comment here with your real name
  • PR's commit messages follow the commit message format

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

@IgorMinar
Copy link
Contributor Author

@kseamon please review this PR. I've modified your commit slightly and added tests.

@petebacondarwin
Copy link
Member

I guess this assumes that the watch functions themselves (as opposed to watch handlers) are in fact idempotent and have no side-effects?

@kseamon
Copy link
Contributor

kseamon commented Dec 5, 2013

LGTM

@kseamon
Copy link
Contributor

kseamon commented Dec 5, 2013

@pete - It does, but the old behavior did as well. If we couldn't assume that the watch value functions were without side-effects then we'd have to iterate forever.

@petebacondarwin
Copy link
Member

I guess this was always an assumption but it could have been possible for a
watch function to have "stable" side effects that stabilized within 10
digest iterations
On 5 Dec 2013 13:10, "Karl Seamon" notifications@github.com wrote:

@pete https://github.com/pete - It does, but the old behavior did as
well. If we couldn't assume that the watch value functions were without
side-effects then we'd have to iterate forever.


Reply to this email directly or view it on GitHubhttps://github.com//pull/5287#issuecomment-29896009
.

@pete
Copy link

pete commented Dec 5, 2013

@kseamon Sure. I'm in favor of that.

@IgorMinar IgorMinar closed this in d070450 Dec 5, 2013
@rino65
Copy link

rino65 commented Dec 23, 2013

Hi
regarding "idempotent" , I have a use case that has a problem with this change.
my watch methods can add and remove other watches , and I noticed that during the digest watcher array loop , if I remove a watch whose index is below the current variable length value of the loop , the watcher array is shifted to the left , and next iteration length-- will point to the same watch as the previous one because all elements are shifted and I get watch === lastDirtyWatch and break from traverseSceopesLoop
and all the other watches dont get called I need the others to get called as well.

@kseamon
Copy link
Contributor

kseamon commented Dec 23, 2013

All righty. You should probably file a separate ticket for this, but the simple solution is to clear the lastDirtyWatch variable whenever an unwatch call is made.

Sent from my iPhone

On Dec 23, 2013, at 9:45 AM, rino65 notifications@github.com wrote:

Hi
regarding "idempotent" , I have a use case that has a problem with this change.
my watch methods can add and remove other watches , and I noticed that during the digest watcher array loop , if I remove a watch whose index is below the current variable length value of the loop , the watcher array is shifted to the left , and next iteration length-- will point to the same watch as the previous one because all elements are shifted and I get watch === lastDirtyWatch and break from traverseSceopesLoop
and all the other watches dont get called I need the others to get called as well.


Reply to this email directly or view it on GitHub.

@rino65
Copy link

rino65 commented Dec 25, 2013

opened issue on this
#5525

jamesdaily pushed a commit to jamesdaily/angular.js that referenced this pull request Jan 27, 2014
Stop dirty-checking during $digest after the last dirty watcher has been re-checked.

This prevents unneeded re-checking of the remaining watchers (They were already
checked in the previous iteration), bringing a substantial performance improvement
to the average case run time of $digest.

Closes angular#5272
Closes angular#5287
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this pull request Jan 27, 2014
Stop dirty-checking during $digest after the last dirty watcher has been re-checked.

This prevents unneeded re-checking of the remaining watchers (They were already
checked in the previous iteration), bringing a substantial performance improvement
to the average case run time of $digest.

Closes angular#5272
Closes angular#5287
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants