New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Object.observe #3601

Closed
jpillora opened this Issue Aug 15, 2013 · 30 comments

Comments

Projects
None yet
@jpillora

jpillora commented Aug 15, 2013

Couldn't find an issue about this, but if one does, please link and I'll close :)

I see there's an ObjectObserve branch but it hasn't been touched in a year. And this post by Misko. I can't find Object.observe in the Angular source, though it could be hiding...

Chrome has had Object.observe since version 25 (http://www.chromestatus.com/features/6147094632988672). Are there plans to drop it in and use it when available?

Edit: It's been in Chrome for a long time, though as @bobslaede points out, it's still under the "Enable Experimental JavaScript" flag.

Demo: http://jsfiddle.net/jpillora/wvA64/

@bobslaede

This comment has been minimized.

Show comment
Hide comment
@bobslaede

bobslaede Aug 15, 2013

I'm not sure it's not only in Canary, and it is still behind a flag I think.

bobslaede commented Aug 15, 2013

I'm not sure it's not only in Canary, and it is still behind a flag I think.

@jpillora

This comment has been minimized.

Show comment
Hide comment
@jpillora

jpillora Aug 15, 2013

Run the demo I've linked. I'm on Chrome Version 28.0.1500.95 Stable and it runs. According to the chromestatus page (also linked), it's been in stable since Version 25

jpillora commented Aug 15, 2013

Run the demo I've linked. I'm on Chrome Version 28.0.1500.95 Stable and it runs. According to the chromestatus page (also linked), it's been in stable since Version 25

@jpillora

This comment has been minimized.

Show comment
Hide comment
@jpillora

jpillora Aug 15, 2013

Damn! Just checked, I've got "Enable Experimental JavaScript" flag on. My mistake :(

jpillora commented Aug 15, 2013

Damn! Just checked, I've got "Enable Experimental JavaScript" flag on. My mistake :(

@bobslaede

This comment has been minimized.

Show comment
Hide comment
@bobslaede

bobslaede Aug 15, 2013

I just did in Chrome 28.0.1500.95 on windows. It didn't run.

bobslaede commented Aug 15, 2013

I just did in Chrome 28.0.1500.95 on windows. It didn't run.

@bobslaede

This comment has been minimized.

Show comment
Hide comment
@bobslaede

bobslaede commented Aug 15, 2013

:)

@IgorMinar

This comment has been minimized.

Show comment
Hide comment
@IgorMinar

IgorMinar Aug 23, 2013

Member

we are working on O.o() but as you observed it's going to be a while before O.o() is wildly available in production.

we don't have enough of O.o() integration ready to share it as a branch, but stay tuned. @jankuca and @btford are on it.

Member

IgorMinar commented Aug 23, 2013

we are working on O.o() but as you observed it's going to be a while before O.o() is wildly available in production.

we don't have enough of O.o() integration ready to share it as a branch, but stay tuned. @jankuca and @btford are on it.

@piether

This comment has been minimized.

Show comment
Hide comment
@piether

piether May 21, 2014

What's the status on this? Object.observe is supported by Chrome 36. http://www.chromestatus.com/features/6147094632988672

piether commented May 21, 2014

What's the status on this? Object.observe is supported by Chrome 36. http://www.chromestatus.com/features/6147094632988672

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp May 21, 2014

Contributor

O.o is being worked on by @EisenbergEffect for https://github.com/angular/watchtower.js at the moment, and will be used in v2.0.0

However it's unlikely that we can leverage it in 1.x. It may be feasible, but it's not something that will necessarily make it into 1.x without significant refactoring to the current dirtychecking algorithm

Contributor

caitp commented May 21, 2014

O.o is being worked on by @EisenbergEffect for https://github.com/angular/watchtower.js at the moment, and will be used in v2.0.0

However it's unlikely that we can leverage it in 1.x. It may be feasible, but it's not something that will necessarily make it into 1.x without significant refactoring to the current dirtychecking algorithm

@btford

This comment has been minimized.

Show comment
Hide comment
@btford

btford May 21, 2014

Contributor

I'm going to close this issue because it's not particularly actionable, but thanks everyone for your interest! As @caitp mentioned, you can track the progress of our new change detection library in the watchtower.js repo.

Contributor

btford commented May 21, 2014

I'm going to close this issue because it's not particularly actionable, but thanks everyone for your interest! As @caitp mentioned, you can track the progress of our new change detection library in the watchtower.js repo.

@btford btford closed this May 21, 2014

@kevin-smets

This comment has been minimized.

Show comment
Hide comment
@kevin-smets

kevin-smets Oct 1, 2014

Just inquiring, leveraging O.o() in 1.x will never be done? The performance on a low end Android is unbearable once you hit like 400 watchers (Samsung Galaxy Tab). I am not using the built in WebView but include a Chromium engine (v36) in my apk so it supports O.o().

This would sure make a big difference so that's why I'm just wondering if it ever will be an option, I'm not getting my hopes up, but still, can't hurt to check, no? Thanks!

kevin-smets commented Oct 1, 2014

Just inquiring, leveraging O.o() in 1.x will never be done? The performance on a low end Android is unbearable once you hit like 400 watchers (Samsung Galaxy Tab). I am not using the built in WebView but include a Chromium engine (v36) in my apk so it supports O.o().

This would sure make a big difference so that's why I'm just wondering if it ever will be an option, I'm not getting my hopes up, but still, can't hurt to check, no? Thanks!

@DexterMorg4n

This comment has been minimized.

Show comment
Hide comment
@DexterMorg4n

DexterMorg4n Oct 29, 2014

Very interested in the O.o(). Is it already included in the latest AngularJS or do we have to write it ourselves ? Today HTML5 is turned into a standard so we can safely say the O.O() will be widely adopted, if it isn't already everywhere.

Just wanted to know if I start writing or not. For larger sets $watch does create problems.

DexterMorg4n commented Oct 29, 2014

Very interested in the O.o(). Is it already included in the latest AngularJS or do we have to write it ourselves ? Today HTML5 is turned into a standard so we can safely say the O.O() will be widely adopted, if it isn't already everywhere.

Just wanted to know if I start writing or not. For larger sets $watch does create problems.

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 29, 2014

Contributor

Very interested in the O.o(). Is it already included in the latest AngularJS or do we have to write it ourselves ? Today HTML5 is turned into a standard so we can safely say the O.O() will be widely adopted, if it isn't already everywhere.

Just wanted to know if I start writing or not. For larger sets $watch does create problems.

V8 is the only engine which implements O.o, and it's ridiculously slow in comparison to dirtychecking in angular.

It will not be included in 1.x, and is not likely to be included in 2.x if it doesn't get picked up by additional browsers, and doesn't improve in speed.

Contributor

caitp commented Oct 29, 2014

Very interested in the O.o(). Is it already included in the latest AngularJS or do we have to write it ourselves ? Today HTML5 is turned into a standard so we can safely say the O.O() will be widely adopted, if it isn't already everywhere.

Just wanted to know if I start writing or not. For larger sets $watch does create problems.

V8 is the only engine which implements O.o, and it's ridiculously slow in comparison to dirtychecking in angular.

It will not be included in 1.x, and is not likely to be included in 2.x if it doesn't get picked up by additional browsers, and doesn't improve in speed.

@DexterMorg4n

This comment has been minimized.

Show comment
Hide comment
@DexterMorg4n

DexterMorg4n Oct 29, 2014

Hmm.. Thanks. How come all benchmarks (at least everything I could find) shows O.o() as being a lot faster ? Example :: http://www.html5rocks.com/en/tutorials/es7/observe/

DexterMorg4n commented Oct 29, 2014

Hmm.. Thanks. How come all benchmarks (at least everything I could find) shows O.o() as being a lot faster ? Example :: http://www.html5rocks.com/en/tutorials/es7/observe/

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 29, 2014

Contributor

You mean from this quote?

For example, last year Angular found that in a benchmark where changes were being made to a model, dirty-checking took 40ms per update and O.o() took 1-2ms per update (an improvement of 20-40x faster).

Performance of O.o is still being worked on in v8, and may improve over the course of the near future. But unfortunately, as-is, it prevents some optimizations, and requires a lot of special casing in various algorithms which include hacks --- and the whole recording and queueing of changes is not cheap, unfortunately.

We will hopefully see performance improve, but for the time being it's not really there. And even if it were there, v8 is only one piece of the market.

Contributor

caitp commented Oct 29, 2014

You mean from this quote?

For example, last year Angular found that in a benchmark where changes were being made to a model, dirty-checking took 40ms per update and O.o() took 1-2ms per update (an improvement of 20-40x faster).

Performance of O.o is still being worked on in v8, and may improve over the course of the near future. But unfortunately, as-is, it prevents some optimizations, and requires a lot of special casing in various algorithms which include hacks --- and the whole recording and queueing of changes is not cheap, unfortunately.

We will hopefully see performance improve, but for the time being it's not really there. And even if it were there, v8 is only one piece of the market.

@DexterMorg4n

This comment has been minimized.

Show comment
Hide comment
@DexterMorg4n

DexterMorg4n Oct 29, 2014

Thanks for your answer. I work a lot with angular on some very big projects, happy with it, the only performance issues are on large data sets, mostly standard data.

Would you advise for or against using O.o() for basic use of large data sets ? For the ones with enhanced functionality I'm quite happy with Ang

DexterMorg4n commented Oct 29, 2014

Thanks for your answer. I work a lot with angular on some very big projects, happy with it, the only performance issues are on large data sets, mostly standard data.

Would you advise for or against using O.o() for basic use of large data sets ? For the ones with enhanced functionality I'm quite happy with Ang

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 29, 2014

Contributor

I haven't done benchmarks there, and v8 does not have perf tests in the tree for its observe mechanism. That said, we know it's expensive, you can see the expense yourself if you use it (Rob Eisenberg found (wrote?) a jsperf which showed how bad it did, and it didn't really fare well there).

It's an ES7 feature, not ES6, and since V8 is the only engine with an implementation, so it doesn't make a whole lot of sense to use it in production, anyways.

Contributor

caitp commented Oct 29, 2014

I haven't done benchmarks there, and v8 does not have perf tests in the tree for its observe mechanism. That said, we know it's expensive, you can see the expense yourself if you use it (Rob Eisenberg found (wrote?) a jsperf which showed how bad it did, and it didn't really fare well there).

It's an ES7 feature, not ES6, and since V8 is the only engine with an implementation, so it doesn't make a whole lot of sense to use it in production, anyways.

@olostan

This comment has been minimized.

Show comment
Hide comment
@olostan

olostan Oct 29, 2014

Contributor

Did anybody found jsperf or other proof that O.o is much slower for simple cases (like $scope.$watch('obj.prop',...? In my apps this type of watchers are most often used.

Contributor

olostan commented Oct 29, 2014

Did anybody found jsperf or other proof that O.o is much slower for simple cases (like $scope.$watch('obj.prop',...? In my apps this type of watchers are most often used.

@nilskp

This comment has been minimized.

Show comment
Hide comment
@nilskp

nilskp Oct 30, 2014

@caitp it's a little worrying that you write that we may not even see this in 2.x, because of lack of browser support, yet 2.x is written in Dart, which will also likely never be supported by anything but Chrome. I understand that Dart can be transpiled to JS, but with proper design, the O.o functionality could be encapsulated and have a dirty-checking fallback, determined at runtime.

nilskp commented Oct 30, 2014

@caitp it's a little worrying that you write that we may not even see this in 2.x, because of lack of browser support, yet 2.x is written in Dart, which will also likely never be supported by anything but Chrome. I understand that Dart can be transpiled to JS, but with proper design, the O.o functionality could be encapsulated and have a dirty-checking fallback, determined at runtime.

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 30, 2014

Contributor

what makes you think 2.x is written in dart?

Contributor

caitp commented Oct 30, 2014

what makes you think 2.x is written in dart?

@nilskp

This comment has been minimized.

Show comment
Hide comment
@nilskp

nilskp Oct 30, 2014

That was a misunderstanding on my part. I see now that it's a parallel development. Does that mean that the Dart->JS is not reliable enough to have a single code base?

However, that was not my main point. I see there's even a polyfill for O.o, which could be another solution, although I don't know if that would end up even slower than current dirty checking.

nilskp commented Oct 30, 2014

That was a misunderstanding on my part. I see now that it's a parallel development. Does that mean that the Dart->JS is not reliable enough to have a single code base?

However, that was not my main point. I see there's even a polyfill for O.o, which could be another solution, although I don't know if that would end up even slower than current dirty checking.

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 30, 2014

Contributor

to be honest I have no idea why we're transpiling to dart rather than dart to js, I thought it would make more sense to transpile to JS since that transpiler already exists --- but in any case, O.o is slow, and it's limited in some ways, so it takes a lot of care to make it work. Rob has done some experiments with it, but it's not clear that it's worth using.

Contributor

caitp commented Oct 30, 2014

to be honest I have no idea why we're transpiling to dart rather than dart to js, I thought it would make more sense to transpile to JS since that transpiler already exists --- but in any case, O.o is slow, and it's limited in some ways, so it takes a lot of care to make it work. Rob has done some experiments with it, but it's not clear that it's worth using.

@nilskp

This comment has been minimized.

Show comment
Hide comment
@nilskp

nilskp Oct 30, 2014

Unrelated to O.o specifically, do you know of any changes in 2.0 that would give users better control over digest cycle? It's my guess that part of what makes Angular slow on even medium data sets, is excessive dirty checking and/or digestion.

nilskp commented Oct 30, 2014

Unrelated to O.o specifically, do you know of any changes in 2.0 that would give users better control over digest cycle? It's my guess that part of what makes Angular slow on even medium data sets, is excessive dirty checking and/or digestion.

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 30, 2014

Contributor

honestly I have hardly even looked at the current prototype of 2.0, so I am far from an expert on it. I would like to get more into it, though.

Contributor

caitp commented Oct 30, 2014

honestly I have hardly even looked at the current prototype of 2.0, so I am far from an expert on it. I would like to get more into it, though.

@EisenbergEffect

This comment has been minimized.

Show comment
Hide comment
@EisenbergEffect

EisenbergEffect Oct 30, 2014

Actually, O.o wasn't that slow. It depended how it was used. An important
thing to note is that it scales differently than dirty checking. O.o can
handle larger sets of bindings easier, but might take more time to set up.
Dirty checking might be quicker to set up, and is fast for a small amount
of bindings, but doesn't do as well as things grow. Also, I say "might"
because extensive tests haven't really been done to test a variety of
scenarios and to test different aspects of performance, such as setup time
vs. cost of notification. These two beasts are quite different in nature.

On Thu, Oct 30, 2014 at 11:06 AM, Caitlin Potter notifications@github.com
wrote:

honestly I have hardly even looked at the current prototype of 2.0, so I
am far from an expert on it. I would like to get more into it, though.


Reply to this email directly or view it on GitHub
#3601 (comment).

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

EisenbergEffect commented Oct 30, 2014

Actually, O.o wasn't that slow. It depended how it was used. An important
thing to note is that it scales differently than dirty checking. O.o can
handle larger sets of bindings easier, but might take more time to set up.
Dirty checking might be quicker to set up, and is fast for a small amount
of bindings, but doesn't do as well as things grow. Also, I say "might"
because extensive tests haven't really been done to test a variety of
scenarios and to test different aspects of performance, such as setup time
vs. cost of notification. These two beasts are quite different in nature.

On Thu, Oct 30, 2014 at 11:06 AM, Caitlin Potter notifications@github.com
wrote:

honestly I have hardly even looked at the current prototype of 2.0, so I
am far from an expert on it. I would like to get more into it, though.


Reply to this email directly or view it on GitHub
#3601 (comment).

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 30, 2014

Contributor

You should think about contributing a perf-test for O.o to v8, since you've had a chance to work with it and a few other dirty checking strategies. We definitely want to make O.o reasonable

Contributor

caitp commented Oct 30, 2014

You should think about contributing a perf-test for O.o to v8, since you've had a chance to work with it and a few other dirty checking strategies. We definitely want to make O.o reasonable

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Oct 30, 2014

Contributor

that said, the typical perf benchmarks on jsperf will show O.o as way, way worse, which is sad. It makes just touching properties of watched objects that much slower.

Contributor

caitp commented Oct 30, 2014

that said, the typical perf benchmarks on jsperf will show O.o as way, way worse, which is sad. It makes just touching properties of watched objects that much slower.

@lega911

This comment has been minimized.

Show comment
Hide comment
@lega911

lega911 Feb 9, 2015

Angular Light (dev version) works with Object.observe, it can be up to 30 times faster (and more) than Angular.js jsperf, for old browsers (IE8+) it uses dirty-checking.

lega911 commented Feb 9, 2015

Angular Light (dev version) works with Object.observe, it can be up to 30 times faster (and more) than Angular.js jsperf, for old browsers (IE8+) it uses dirty-checking.

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Feb 9, 2015

Contributor

@lega911 there are a number of problems with that benchmark.

  1. It's only measuring the time taken to set up watches and process 0 changes (this record keeping in O.o is the main performance pain).
  2. Each benchmark is performing very different tasks and are not really comparable
Contributor

caitp commented Feb 9, 2015

@lega911 there are a number of problems with that benchmark.

  1. It's only measuring the time taken to set up watches and process 0 changes (this record keeping in O.o is the main performance pain).
  2. Each benchmark is performing very different tasks and are not really comparable
@lega911

This comment has been minimized.

Show comment
Hide comment
@lega911

lega911 Feb 9, 2015

this record keeping in O.o is the main performance pain.

O.o can be slow, but it can save time that dirty-checking spends in big applications.

lega911 commented Feb 9, 2015

this record keeping in O.o is the main performance pain.

O.o can be slow, but it can save time that dirty-checking spends in big applications.

@gajus

This comment has been minimized.

Show comment
Hide comment
@gajus

gajus Nov 2, 2015

Object.observe proposal is being withdrawn, https://twitter.com/gdi2290/status/661257618820694016:

After much discussion with the parties involved, I plan to withdraw the
Object.observe proposal from TC39 (where it currently sits at stage 2 in
the ES spec process), and hope to remove support from V8 by the end of the
year (the feature is used on 0.0169% of Chrome pageviews, according to
chromestatus.com).

gajus commented Nov 2, 2015

Object.observe proposal is being withdrawn, https://twitter.com/gdi2290/status/661257618820694016:

After much discussion with the parties involved, I plan to withdraw the
Object.observe proposal from TC39 (where it currently sits at stage 2 in
the ES spec process), and hope to remove support from V8 by the end of the
year (the feature is used on 0.0169% of Chrome pageviews, according to
chromestatus.com).

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