Live data from Hacker News

Improving Angular performance with 1 line of code

medium.com

71–80 of 118 posts

Re: Improving Angular performance with 1 line of code

#71

As someone who's specialized in AngularJS optimization [0], this doesn't surprise me in the least. Developers leave plenty of performance optimizations on the table, some worse than this one. The truth of the matter is that in the general case, it doesn't matter. We engineers like to go on and on about this or that perf efficiency but most of the time the code runs fast enough (and the majority of the time when it do…

> most of the time the code runs fast enough

Tell that to my Nexus 5 struggling to render a basic news article of 1000 words and a few images.

Re: Improving Angular performance with 1 line of code

#72
post #63

Earlier quoted context omitted.

Keep in mind Angular is a framework where, when you pass it a callback function, it will sometimes behave differently depending on what you named the function's parameters. @_@ (Or at least it used to when last I checked. It does it by calling toString on the function and parsing the result.)

This is known as Dependency Injection and makes testing and codebase componentization a breeze. You may have seen it called "inversion of control" elsewhere. In essence, my components define what they need to run (through the function params) and Angular hands it to them. For instance: myApp.service('foo', function (bar, baz) { registers a service named `foo` that depends on the `bar` and `baz` components. My service…

Cheers for the explanation, but this isn't so much "DI", as "reflection for the sake of DI", right? I mean, libraries can have DI without being quite this magical.

I say this naively as a non-user, but in my case this specifically is what made me decide not to use Angular. I was trying it out for a new project and running through tutorials, but when I realized it was being that clever behind the scenes I decided that learning all its quirks would take longer than the rest of the project, and switched to something way simpler.

Re: Improving Angular performance with 1 line of code

#73

As someone who's specialized in AngularJS optimization [0], this doesn't surprise me in the least. Developers leave plenty of performance optimizations on the table, some worse than this one. The truth of the matter is that in the general case, it doesn't matter. We engineers like to go on and on about this or that perf efficiency but most of the time the code runs fast enough (and the majority of the time when it do…

1) Make it work

2) ???

3) Make it work fast

Re: Improving Angular performance with 1 line of code

#74
post #60

Earlier quoted context omitted.

The tone of your comment sounds like you think I said one should never look at performance. I do this professionally, I should hope folks out there need performance. Let me be clear: A developer should place performance priority in the Right Place, and a good dev will know where that is. Would you mind linking a few of these studies? I'm curious as to what the point of diminishing returns is. nngroup [0] says that 10…

>So a mediocre application has 5x space to grow before the app stops feeling instantaneous. Not really. Those 100ms are from click to render done, so you also need to account for the physical transmission latency, the transmission of the data and finally the rendering (which is where your 16-20ms are).

And you upgrade your machine not when the response time goes up, but when the response time goes up too much.

Re: Improving Angular performance with 1 line of code

#75
post #72

Earlier quoted context omitted.

This is known as Dependency Injection and makes testing and codebase componentization a breeze. You may have seen it called "inversion of control" elsewhere. In essence, my components define what they need to run (through the function params) and Angular hands it to them. For instance: myApp.service('foo', function (bar, baz) { registers a service named `foo` that depends on the `bar` and `baz` components. My service…

Cheers for the explanation, but this isn't so much "DI", as "reflection for the sake of DI", right? I mean, libraries can have DI without being quite this magical. I say this naively as a non-user, but in my case this specifically is what made me decide not to use Angular. I was trying it out for a new project and running through tutorials, but when I realized it was being that clever behind the scenes I decided that…

When I've implemented (toy) DI in C#, I've also used reflection. How else are you finding the types to load? (Happy to see examples in other languages, too)

Re: Improving Angular performance with 1 line of code

#76

I've searched a few minutes for any blog post or article which demonstrates the performance difference between turning this setting on or off, and I haven't found anything. If you don't have a benchmark, you don't have a performance boost.

Given the condescending tone of this article, you'd think the author has some data to back himself up.

I guess after checking 77 web pages if they have this flag enabled or not he didnt have any time left for actual performance testing.

Re: Improving Angular performance with 1 line of code

#77
post #56

Earlier quoted context omitted.

>>unless you've got a confirmed performance problem, you shouldn't think about it at all. I like to write high quality code that I'm proud of. This means code not just works, but works efficiently and fast. It goes back to what Steve Jobs said once: “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever s…

Interesting to note that generally even quite nice sets of draws have cheap wood at the back...

You have watched too much Norm Abram. Put down the remote and go outside.

Re: Improving Angular performance with 1 line of code

#78

As someone who's specialized in AngularJS optimization [0], this doesn't surprise me in the least. Developers leave plenty of performance optimizations on the table, some worse than this one. The truth of the matter is that in the general case, it doesn't matter. We engineers like to go on and on about this or that perf efficiency but most of the time the code runs fast enough (and the majority of the time when it do…

Some deoptimizations are ahead-of-time planted to make performances increases easy to enable in the future. http://thedailywtf.com/articles/The-Speedup-Loop

I have a better solution to this problem.

I optimize one module at a time, and I optimize it deeply. The number of people whose stuff I might break is kept to a minimum, the surface area of regression testing is controlled, and next quarter when they ask me for more power I can repeat it, until I run out of modules (hopefully someone will write some more in the meantime).

The whole idea of the Tall Tent Pole is pretty enticing, but the thing is nobody is ever gonna buy into going back for the last 20% in any one part, and these things always have a multiplicative factor. If you're in a field with no competition, this isn't a big deal, but how often does that happen?

Re: Improving Angular performance with 1 line of code

#79

This is a case of bad defaults - why should a developer be required to write code, even if it is a one liner, to _disable_ debug? It should be the other way around - you write a single liner to enable debug.

It should be on for test and dev builds, and off for production.

Re: Improving Angular performance with 1 line of code

#80

This is a case of bad defaults - why should a developer be required to write code, even if it is a one liner, to _disable_ debug? It should be the other way around - you write a single liner to enable debug.

That particular flag wasn't released until version 1.3 so by opting in rather than out it wasn't released as a breaking change.

When it was released and we tried to use it, it broke our site entirely due to third-party libraries we were using.

Post reply on HN