6 ms·

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

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 doesn't, ads are to blame over framework tweaks). Heck, I shouldn't even be saying this as it'll cut into my very lucrative field but unless you've got a confirmed performance problem, you shouldn't think about it at all. Really. Leave all of the fancy perf tweaks behind. Sure, you might get ridiculed on Medium but that's par for the course here on the internet. I'm afraid articles like these will cause lots of cargo-cult 'optimization' that just makes the job harder for future devs. Make it work, make it work well, THEN make it work fast. [0] I wrote Batarang's new perf panel before Google abandoned the project

jsprogrammer 10y ago
Some deoptimizations are ahead-of-time planted to make performances increases easy to enable in the future. http://thedailywtf.com/articles/The-Speedup-Loop http://thedailywtf.com/articles/The-Speedup-Loop
- hinkley 10y ago
  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?
joshschreuder 10y ago
Tried this out on a work project a month or two ago, found it worked quite well and had a noticeable performance boost. Unfortunately a bunch of inherited legacy code uses angular.element().scope() in a lot of places which then breaks without this turned on, so I had to revert it.
acomjean 10y ago
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. " -Donald Knuth [1] [1]https://books.google.com/books?id=SJHvCgAAQBAJ&pg=PT471&lpg=PT471&dq=Programmers+waste+enormous+amounts+of+time+thinking+about,+or+worrying+about,+the+speed+of+noncritical+parts+of+their+programs,+and&source=bl&ots=qyjHBSjYp8&sig=8REWN9Ixkx0whhCzehHRjljQkj0&hl=en&sa=X&ved=0ahUKEwih1PGRgb_MAhVBtYMKHVJNDp0Q6AEIOTAF#v=onepage&q=Programmers%20waste%20enormous%20amounts%20of%20time%20thinking%20about%2C%20or%20worrying%20about%2C%20the%20speed%20of%20noncritical%20parts%20of%20their%20programs%2C%20and&f=false https://books.google.com/books?id=SJHvCgAAQBAJ&pg=PT471&lpg=...
sbov 10y ago
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.
- RKoutnik 10y ago
  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 100ms feels instantaneous. A good digest cycle run (the basic unit of Angular performance) is 16ms, a mediocre one is 20ms. So a mediocre application has 5x space to grow before the app stops feeling instantaneous. [0] https://www.nngroup.com/articles/website-response-times/ https://www.nngroup.com/articles/website-response-times/
  - Tehnix 10y ago
    >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).
    - hinkley 10y ago
      And you upgrade your machine not when the response time goes up, but when the response time goes up too much.
  - xenadu02 10y ago
    And what makes it OK to burn X% additional battery life across all your users devices? I take your general point but battery life is also a problem I have with React Native. Sure, you can drive animations from the JS thread and on modern devices in some cases you can't even tell the difference. But your battery can.
enraged_camel 10y ago
>>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.
- RKoutnik 10y ago
  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.
- PJDK 10y ago
  Interesting to note that generally even quite nice sets of draws have cheap wood at the back...
  - jholman 10y ago
    Yeah, what kind of asshole carpenter wastes his customer's money by inflating materials costs for no reason?
    - z4chj 10y ago
      The same kind that was the CEO of one of the most successful companies in the history of the world. Steve Jobs may have missed the mark on some of his products during his long tenure at Apple, but his focus on quality in every possible area of what he had a part in creating has paid its benefits
blt 10y ago
> 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.
- RKoutnik 10y ago
  I'd put dollars to doughnuts the slowdown is caused by ads & trackers, not a lack of framework-specific perf tweaks.
  - blt 10y ago
    So terrible performance is OK if it's caused by ads & trackers? They don't count as part of a page's Javascript payload?
    - jbigelow76 10y ago
      If you're going to complain about the slowness of pages because of the idiosyncrasies of one library over another, then complain about that. If you're going to complain about the slowness of pages due to trackers and ad servers regardless of which library (or none at all) is used for primary content formatting, then complain about that. You're talking apples while holding up an orange.
- guftagu 10y ago
  Use Firefox Mobile with uBlock. It's been a long time since I've seen ads on web
hinkley 10y ago
1) Make it work 2) ??? 3) Make it work fast
dmitrygr 10y ago
>>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 THIS! This is why battery life on mobile sucks everyone who thinks this way is the reason . As everything moves to the web, the performance of your code matters . So what if my phone has just enough CPU to render your site? You should not be content with that - you should strive to use less, so my CPU can go to sleep faster. . Your job is supposed to be hard. you're an engineer! Please consider the consequences of your actions.
- booop 10y ago
  I like this comment and I'd add one more thing: Yes developers your developer-time is the most precious thing in the universe but please consider your user's time and their computing resources as well.
  - pmontra 10y ago
    It's a customer's decision, not a developer's one. A one liner like the one in the post should be added at zero cost by any developer, but more important optimizations compete with the budget of the features that sell the product of the customer. In my experience customers want features first, optimizations last and only if the unoptimized app/site runs too slow on their devices. And developers don't like to work for free.
    - booop 10y ago
      Even if the customer doesn't demand it, you should have your own standards for quality and performance and never compromise on them when it comes to your deliverables. You're actually harming your business if you choose to do shitty work for small bucks and good work for big bucks. If you take your standards very seriously it improves the capabilities of your team and let's you take on more lucrative contracts. > And developers don't like to work for free. Oddly enough, the highest earning developers I know don't think like that.
n72 10y ago
Is there a linter or some such which will catch the most common of these mistakes?

jsprogrammer 10y ago

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

hinkley 10y ago
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?

joshschreuder 10y ago

Tried this out on a work project a month or two ago, found it worked quite well and had a noticeable performance boost. Unfortunately a bunch of inherited legacy code uses angular.element().scope() in a lot of places which then breaks without this turned on, so I had to revert it.

acomjean 10y ago

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. " -Donald Knuth [1] [1]https://books.google.com/books?id=SJHvCgAAQBAJ&pg=PT471&lpg=PT471&dq=Programmers+waste+enormous+amounts+of+time+thinking+about,+or+worrying+about,+the+speed+of+noncritical+parts+of+their+programs,+and&source=bl&ots=qyjHBSjYp8&sig=8REWN9Ixkx0whhCzehHRjljQkj0&hl=en&sa=X&ved=0ahUKEwih1PGRgb_MAhVBtYMKHVJNDp0Q6AEIOTAF#v=onepage&q=Programmers%20waste%20enormous%20amounts%20of%20time%20thinking%20about%2C%20or%20worrying%20about%2C%20the%20speed%20of%20noncritical%20parts%20of%20their%20programs%2C%20and&f=false https://books.google.com/books?id=SJHvCgAAQBAJ&pg=PT471&lpg=...

sbov 10y ago

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.

RKoutnik 10y ago
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 100ms feels instantaneous. A good digest cycle run (the basic unit of Angular performance) is 16ms, a mediocre one is 20ms. So a mediocre application has 5x space to grow before the app stops feeling instantaneous. [0] https://www.nngroup.com/articles/website-response-times/ https://www.nngroup.com/articles/website-response-times/
- Tehnix 10y ago
  >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).
  - hinkley 10y ago
    And you upgrade your machine not when the response time goes up, but when the response time goes up too much.
- xenadu02 10y ago
  And what makes it OK to burn X% additional battery life across all your users devices? I take your general point but battery life is also a problem I have with React Native. Sure, you can drive animations from the JS thread and on modern devices in some cases you can't even tell the difference. But your battery can.

enraged_camel 10y ago

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

RKoutnik 10y ago
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.
PJDK 10y ago
Interesting to note that generally even quite nice sets of draws have cheap wood at the back...
- jholman 10y ago
  Yeah, what kind of asshole carpenter wastes his customer's money by inflating materials costs for no reason?
  - z4chj 10y ago
    The same kind that was the CEO of one of the most successful companies in the history of the world. Steve Jobs may have missed the mark on some of his products during his long tenure at Apple, but his focus on quality in every possible area of what he had a part in creating has paid its benefits

blt 10y ago

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

RKoutnik 10y ago
I'd put dollars to doughnuts the slowdown is caused by ads & trackers, not a lack of framework-specific perf tweaks.
- blt 10y ago
  So terrible performance is OK if it's caused by ads & trackers? They don't count as part of a page's Javascript payload?
  - jbigelow76 10y ago
    If you're going to complain about the slowness of pages because of the idiosyncrasies of one library over another, then complain about that. If you're going to complain about the slowness of pages due to trackers and ad servers regardless of which library (or none at all) is used for primary content formatting, then complain about that. You're talking apples while holding up an orange.
guftagu 10y ago
Use Firefox Mobile with uBlock. It's been a long time since I've seen ads on web

hinkley 10y ago

1) Make it work 2) ??? 3) Make it work fast

dmitrygr 10y ago

>>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 THIS! This is why battery life on mobile sucks everyone who thinks this way is the reason . As everything moves to the web, the performance of your code matters . So what if my phone has just enough CPU to render your site? You should not be content with that - you should strive to use less, so my CPU can go to sleep faster. . Your job is supposed to be hard. you're an engineer! Please consider the consequences of your actions.

booop 10y ago
I like this comment and I'd add one more thing: Yes developers your developer-time is the most precious thing in the universe but please consider your user's time and their computing resources as well.
- pmontra 10y ago
  It's a customer's decision, not a developer's one. A one liner like the one in the post should be added at zero cost by any developer, but more important optimizations compete with the budget of the features that sell the product of the customer. In my experience customers want features first, optimizations last and only if the unoptimized app/site runs too slow on their devices. And developers don't like to work for free.
  - booop 10y ago
    Even if the customer doesn't demand it, you should have your own standards for quality and performance and never compromise on them when it comes to your deliverables. You're actually harming your business if you choose to do shitty work for small bucks and good work for big bucks. If you take your standards very seriously it improves the capabilities of your team and let's you take on more lucrative contracts. > And developers don't like to work for free. Oddly enough, the highest earning developers I know don't think like that.

n72 10y ago

Is there a linter or some such which will catch the most common of these mistakes?