I think, Angulars digest (dirty checking) fires every x ms and your hack triggers another digest cycle. this may lead to a more "responsive" feeling in the first place. But did you have a look at your CPU usage. On my machine here, the usage climbs from 2-3 % up to 4-6 %.
As long as your digest durations are small, this shouldn't be a problem afais. We had situations, where a digests' duration was longer than the time between two digests. So the digests stacked up and we got a cpu usage of nearly 100%. I think, some time in the future, the angular team is going to replace the cycle based dirty checking with Javascripts observe mechanism, which will solve these kind of issues imho. 2014-02-12 8:53 GMT+01:00 Thanassis Tsiodras <[email protected]>: > > In our very large and quite complex AngularJS application, I noticed (by > accident!) that a line like this in my main module setup... > > application.run(function($rootScope) { > window.setInterval( () => { $rootScope.$digest(); }, 1000); > }); > > ...has significant positive impact, in the activation time of our > $http.post requests. > > A small part of our code that deterministically reproduces the behaviour > is this: > > // In the partial > <button ... ng-click="buttonHandler" ...> > > // In the controller > $scope.buttonHandler = function() { > $http.post(....).success( function() { console.log("Activated"); }) > } > > We associate a button's ng-click handler with invocation of one of our web > services. The web service itself responds within 30ms (according to Chrome > developer tools). However, the code inside the *.success* handler is > executed after 1.75 - 2.3 seconds (and only then is the message "Activated" > displayed in the console). However, when we put the "*Eternal rootScope > $digest Hack (TM)*" in place, the activation occurs in less than a second! > > I can only guess that the rootScope $digest somehow 'triggers' the actual > invocation of the .*success* handler, and since the webservice itself > responds in 30ms, the activation time depends on when the button press > happens to fall in the 1 second period of the hack's *setInterval.* > > I am not saying that this is a recommended practise - but i was very > surprised to see it happen. Note that there are no console errors logged or > any other mischief reported anywhere in my assertive checks - the code > works fine with or without the hack, but with significantly improved > performance when the hack is in place. > > Any idea what is going on? > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/groups/opt_out. > -- Bernhard Rode M.Sc. (Master of Computer Science and Media) fon +49.171.5629409 mail [email protected] twitter @ebbo google+ *google.com/+BernhardRode <http://www.google.com/+BernhardRode>* twitter twitter.com/ebbo facebook facebook.com/bernhard.rode -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out.
