Search a title or topic

Over 20 million podcasts, powered by 

Player FM logo
Artwork

Content provided by Jim McQuillan & Wolf and Jim McQuillan. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jim McQuillan & Wolf and Jim McQuillan or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Episode 6: Code Performance - Where does the money go?

1:02:07
 
Share
 

Manage episode 494093004 series 3660315
Content provided by Jim McQuillan & Wolf and Jim McQuillan. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jim McQuillan & Wolf and Jim McQuillan or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/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 https://www.RuntimeArguments.fm

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


  continue reading

7 episodes

Artwork
iconShare
 
Manage episode 494093004 series 3660315
Content provided by Jim McQuillan & Wolf and Jim McQuillan. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jim McQuillan & Wolf and Jim McQuillan or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/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 https://www.RuntimeArguments.fm

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


  continue reading

7 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Copyright 2025 | Privacy Policy | Terms of Service | | Copyright
Listen to this show while you explore
Play