Artwork

Вміст надано Jim McQuillan & Wolf and Jim McQuillan. Весь вміст подкастів, включаючи епізоди, графіку та описи подкастів, завантажується та надається безпосередньо компанією Jim McQuillan & Wolf and Jim McQuillan або його партнером по платформі подкастів. Якщо ви вважаєте, що хтось використовує ваш захищений авторським правом твір без вашого дозволу, ви можете виконати процедуру, описану тут https://uk.player.fm/legal.
Player FM - додаток Podcast
Переходьте в офлайн за допомогою програми Player FM !

6: Code Performance - Where does the money go?

1:02:07
 
Поширити
 

Manage episode 494093004 series 3660315
Вміст надано Jim McQuillan & Wolf and Jim McQuillan. Весь вміст подкастів, включаючи епізоди, графіку та описи подкастів, завантажується та надається безпосередньо компанією Jim McQuillan & Wolf and Jim McQuillan або його партнером по платформі подкастів. Якщо ви вважаєте, що хтось використовує ваш захищений авторським правом твір без вашого дозволу, ви можете виконати процедуру, описану тут https://uk.player.fm/legal.

Your programs can be better. There are lots of ways to make them better. It all starts with figuring out what matters and measuring it. Measuring it all the time. Measuring it more. This episode is about following that path.

Show notes:

Take-aways from the episode:

  • Understand what you are optimizing for: (speed,memory,storage,developer, etc…)
  • Measurement is job one, because that’s the only way to know where the money is actually going. You should be measuring. A lot. More than that. It should be part of CI/CD. You should run it before pushing. Everyone should be doing it. Measurement might be even more important than testing (and don’t get me wrong, testing is very important). When I worked on Mozilla, our build servers did timing. If your commit slowed something down, that was considered “bustage”, and required immediate fixing.
  • Use the profiler for two things:
    • To see if the whole thing is faster or slower so you know when it’s time to look deeper
    • To dive into the actual execution and locate the bad parts you need to improve.
  • It’s all about the money.
  • Write clear, simple, and correct (you’ll know by testing) code. Only then should you optimize. Do I need to repeat the old adage about premature optimization? “Premature optimization is the root of all evil.” It’s easier to speed up working code, than it is to fix fast but broken code.
  • Understand the (real) data you will be operating on.
  • You don’t know just by looking at the source what actually costs you the most money. Yes, you can see where stupid things happen, but even for those, knowing which actually matter requires measurement.

Hosts:
Jim McQuillan can be reached at [email protected]
Wolf can be reached at [email protected]
Follow us on Mastodon: @[email protected]

If you have feedback for us, please send it to [email protected]

Checkout our webpage at http://RuntimeArguments.fm

Theme music:
Dawn by nuer self, from the album Digital Sky


  continue reading

11 епізодів

Artwork
iconПоширити
 
Manage episode 494093004 series 3660315
Вміст надано Jim McQuillan & Wolf and Jim McQuillan. Весь вміст подкастів, включаючи епізоди, графіку та описи подкастів, завантажується та надається безпосередньо компанією Jim McQuillan & Wolf and Jim McQuillan або його партнером по платформі подкастів. Якщо ви вважаєте, що хтось використовує ваш захищений авторським правом твір без вашого дозволу, ви можете виконати процедуру, описану тут https://uk.player.fm/legal.

Your programs can be better. There are lots of ways to make them better. It all starts with figuring out what matters and measuring it. Measuring it all the time. Measuring it more. This episode is about following that path.

Show notes:

Take-aways from the episode:

  • Understand what you are optimizing for: (speed,memory,storage,developer, etc…)
  • Measurement is job one, because that’s the only way to know where the money is actually going. You should be measuring. A lot. More than that. It should be part of CI/CD. You should run it before pushing. Everyone should be doing it. Measurement might be even more important than testing (and don’t get me wrong, testing is very important). When I worked on Mozilla, our build servers did timing. If your commit slowed something down, that was considered “bustage”, and required immediate fixing.
  • Use the profiler for two things:
    • To see if the whole thing is faster or slower so you know when it’s time to look deeper
    • To dive into the actual execution and locate the bad parts you need to improve.
  • It’s all about the money.
  • Write clear, simple, and correct (you’ll know by testing) code. Only then should you optimize. Do I need to repeat the old adage about premature optimization? “Premature optimization is the root of all evil.” It’s easier to speed up working code, than it is to fix fast but broken code.
  • Understand the (real) data you will be operating on.
  • You don’t know just by looking at the source what actually costs you the most money. Yes, you can see where stupid things happen, but even for those, knowing which actually matter requires measurement.

Hosts:
Jim McQuillan can be reached at [email protected]
Wolf can be reached at [email protected]
Follow us on Mastodon: @[email protected]

If you have feedback for us, please send it to [email protected]

Checkout our webpage at http://RuntimeArguments.fm

Theme music:
Dawn by nuer self, from the album Digital Sky


  continue reading

11 епізодів

Усі епізоди

×
 
Loading …

Ласкаво просимо до Player FM!

Player FM сканує Інтернет для отримання високоякісних подкастів, щоб ви могли насолоджуватися ними зараз. Це найкращий додаток для подкастів, який працює на Android, iPhone і веб-сторінці. Реєстрація для синхронізації підписок між пристроями.

 

Короткий довідник

Слухайте це шоу, досліджуючи
Відтворити