Lesson 7: Python setup and execution: Performance perspective

Concept Explanation

This lesson is not about turning you into a performance engineer in one day. It is about building a healthy instinct: some code does the same job in a cleaner and faster way, and you should learn how to notice that without becoming obsessed with tiny speed differences. A lot of beginners write something that works, then assume performance is a mysterious topic for later. The truth is simpler. You start by asking practical questions: Am I repeating work? Am I using a tool Python already optimized for me? Am I measuring the result instead of guessing? In this lesson, you will compare two ways to calculate the same total. One version uses a manual loop. The other uses Python's built-in `sum`. Both are correct. The goal is to see how small design choices affect readability and runtime. By the end of this lesson, you will be able to: • measure the runtime of a tiny script without panicking about the numbers, • explain why built-in tools are often a better default than writing everything manually, • spot one obvious performance mistake: doing the same work more times than necessary. Why this matters: performance is easier to learn when you treat it as observation, not magic. If you can measure a small example calmly, bigger performance topics later will make much more sense.

Where to Put the Code

1. Define color and position variables at the top.
2. Create shape drawing or placement logic in the middle.
3. Render output (print, canvas, SVG, or styled block) at the end.

Command Reference

• Run the script more than once before judging the result; one timing alone can be misleading.
• Compare code that solves the same problem, not two completely different tasks.
• Prefer a built-in like `sum()` when it makes the code clearer and removes manual work.
• Measure first, then optimize; guessing about speed is how people waste time.

Step-by-step Guide

1. Run the file once and write down which version finished faster on your machine.
2. Change `limit` to a smaller number like `50_000`, then a larger number like `500_000`, and compare how the timings move.
3. Before each run, predict which version will be faster and why.
4. Edit `total_with_loop()` to do unnecessary extra work inside the loop, run it again, and notice how quickly small inefficiencies add up.
5. Write one sentence explaining the difference between code that is correct and code that is both correct and efficient.

Practice Exercises

• Replace `sum()` with another approach, such as a generator expression or `functools.reduce()`, and compare readability first, speed second.
• Explain why printing inside the part you are timing would make your measurement less useful.
• Think of one real feature where performance matters more than usual, such as processing many rows, serving an API, or updating a game score repeatedly.

Coding Challenges

• Use the arithmetic series formula to compute the same total, then compare it with the loop and built-in versions.
• Write a short note about when you should stop optimizing and accept the clearer solution instead.

Mini Practice Tasks

• Save one run result in your notes so you can compare later experiments.
• Circle the line in the script where the measurement actually starts and ends.
• Delete any deliberately slow test code after you finish so the final version stays clean.