Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving Angular performance with 1 line of code

medium.com

Post reply on HN
Print view View original

51–60 of 118 posts

Re: Improving Angular performance with 1 line of code

#51

Post by visural »

gamache wrote: post #5

I'd like to see some data indicating there is actually an appreciable performance difference. Indeed, with only one line of code to add, the setup cost is low, but this article asserts a performance gain without any evidence.

Not a very rigorous test - but I just applied this to one of our (very) large angular 1.x apps and it had a consistent 20-30% reduction in profiled execution time across the couple of test interactions I did.

That said, I'm not sure it made much perceptible difference as the app already performed adequately and the reduction is amortized across all of the interactions the user makes.

Re: Improving Angular performance with 1 line of code

#52

Post by nothrabannosir »

geofft wrote: post #25
Zekio wrote: post #2

Shouldn't debugging be something you opt-in to rather than opt-out of? Seems like a weird design choice

It's the same design choice as most C compilation toolchains: you get debug symbols during the compilation process, and you can strip the binaries later if you want.

Really? Limited experience, but doesn't GCC require -g to enable debug symbols?

Re: Improving Angular performance with 1 line of code

#53

Post by finleymedia »

imjustsaying wrote: post #44
melvinmt wrote: post #38

Earlier quoted context omitted.

It comes in quite handy when you're dealing with sites that attempt to hide content behind a paywall, with just a front-end solution... #nevertrusttheclient

That still works? Cool. Off the top of your head, do you remember any examples of sites that expose paywalled content like this?

www.kansascity.com

Re: Improving Angular performance with 1 line of code

#54

Post by enraged_camel »

RKoutnik wrote: post #26

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…

>>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 see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

That said, this is more of an ideal to strive towards and it's not always possible. Sometimes there are tight deadlines that need to be met, and something has to give. In such scenarios, I agree with your order of priorities: 1) code that works, 2) code that works well, 3) code that works fast.

Re: Improving Angular performance with 1 line of code

#55

Post by RKoutnik »

enraged_camel wrote: post #54
RKoutnik wrote: post #26

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…

>>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…

Absolutely - I love digging into the core of frameworks & the language itself to eke out every last bit of performance. But that takes time, something I'm usually short of. All of the examples given in the article weren't neat perf side projects, they were live sites with customers & deadlines. I write the best code I can given the constraints I'm under.

Given the chance, we'd all like to write perfect code but reality tends to interfere.

Re: Improving Angular performance with 1 line of code

#56

Post by PJDK »

enraged_camel wrote: post #54
RKoutnik wrote: post #26

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…

>>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...

Re: Improving Angular performance with 1 line of code

#57

Post by enraged_camel »

joesmo wrote: post #27

What the author discovered is really shitty defaults for Angular. Most software is like that. Don't blame the developers using the software, blame the Angular developers for choosing shitty defaults. Instead of choosing production ready defaults, they chose development ready defaults, creating more work for everyone.

>>Don't blame the developers using the software, blame the Angular developers for choosing shitty defaults.

I like to blame developers who don't read the friggin documentation on the software they are using.

This particular suggestion is literally the very first one in the developer guide for running Angular in production: https://docs.angularjs.org/guide/production

Re: Improving Angular performance with 1 line of code

#59

Post by jholman »

PJDK wrote: post #56
enraged_camel wrote: post #54

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...

Yeah, what kind of asshole carpenter wastes his customer's money by inflating materials costs for no reason?

Re: Improving Angular performance with 1 line of code

#60

Post by Tehnix »

RKoutnik wrote: post #45
sbov wrote: post #43

Earlier quoted context omitted.

Depends. There's been lots of studies linking page speed to revenue. I would imagine it doesn't manifest much in lower traffic sites where there's too much noise for it to play out, but as you grow in your userbase, working fast starts to become necessary for it to work well.

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).

Post reply on HN