Coding Practices and Code Performance Analysis for ML

The way we write code in machine learning is fundamentally different from traditional software engineering. In SE, you write every rule explicitly; in ML, the algorithm learns rules from data. This lecture explores what that means for code quality — how to write good ML code, how to measure its performance, and how to find bottlenecks before they reach production.

9.1 Coding in Software Engineering vs. Machine Learning

9.1.1 Core Difference: Explicit Rules vs. Learned Rules

In traditional software engineering (SE), a developer writes decision rules explicitly in code. For example, a loan approval function might contain:

if income > 50000:
    approve()

Or a more detailed version: if the customer age is greater than 60 AND income is less than 30,000, then reject the loan. The developer defines every branching condition by hand. This is the fundamental nature of SE coding — rules are explicit, inspectable, and modifiable.

In machine learning, the rules are learned automatically from data. The developer writes:

model.fit(X_train, y_train)
model.predict(X_new)

The dataset contains customer details (age, income, credit score, existing loans, etc.) as features X, and labels Y (approved or not approved). The algorithm discovers patterns on its own. After training, the model might produce: "If income is high, customer age less than 60, credit score above 700, and existing loans are few, then probability of approval is 92%."

Exam note: Understanding this difference is foundational — it shapes how you debug, how you measure quality, and how you think about code in ML systems.

9.1.2 Five Key Differences Between SE and ML Coding

On generalization (point 3): In SE, functionality is supreme. In ML, the core concern is whether the model performs well on unseen production data — not just on the training or test set. A model may perform well on known data but fail on real-world inputs it has never seen. That gap is what "generalization" addresses.

On debugging (point 4): In SE, you fix the code, and the application works. In ML, you may fix the code and the application still does not give the right outcome. The root cause could be:

• Data problem: bias in the training data, high variance
• Features problem: you are using all features without checking feature importance; irrelevant features drag down accuracy
• Training process problem: hyperparameters, learning rate, number of epochs
• Code problem: only one of several possible root causes

On explainability (point 5): Because rules are embedded in model parameters, they are not intuitive to read line by line. You cannot trace "why this output?" through the code the way you can in SE. This is the motivation behind the entire field of explainable AI — providing rationale for model decisions (not just what happened, but why, and how the user can improve their outcome).

9.1.3 Abstraction at Two Levels in ML

Real-world: This abstraction has accelerated dramatically. Building a chatbot today takes 5-6 lines of code using chat.completions.create, providing API keys, hyperparameters (temperature, etc.), and context documents. The chatbot works across PDFs, Word docs, CSVs, zip files — all handled by the underlying model. Previously, with rule-based frameworks like AIML or early Rasa, every intent and response had to be written manually.

9.1.4 The Evolution of Chatbots: Rule-Based to AI-Enabled

This example illustrates the migration from explicit rules to learned behavior — the same trajectory that defines the SE-to-ML shift:

• First generation (1956–1980s): Rule-based engines. Example: ELIZA (1956). Chatbots used AIML (an XML-based standard) where every intent → response mapping was written manually. If the user input contained certain words, execute a specific rule.
• Second generation (1980s–2010): AI-assisted. The NLP pipeline pre-processes input, understands intents automatically from natural language, handles vocabulary and grammar mistakes. Tools like early Rasa (before 2015-2016) used rules plus some AI.
• Third generation (2010–present): AI-enabled, RAG-based chatbots. Domain knowledge is embedded into a knowledge base. The AI engine, given an intent and entities from the user's input, queries the domain knowledge and generates responses. Examples: Amazon Lex, Google Dialogflow, modern Rasa (open-source Python framework).

Visual Intuition. Picture two flowcharts side by side. The SE flowchart (left) has clear diamond-shaped decision nodes with labels like "income > 50000?" and arrows labeled "yes" and "no." Every path is visible. The ML flowchart (right) has a single box labeled model.predict() that takes input features and outputs a decision — but inside the box is a tangled web of weighted connections with no labels. The takeaway: the ML box works, but you cannot trace a single decision through it the way you can through the SE diamond.

Real-World & Domain Connection. The SE-to-ML coding shift is most visible in modern chatbot platforms. Amazon Lex and Google Dialogflow handle millions of customer service conversations daily. Neither requires a developer to write a single if statement for intent matching. The developer provides example utterances and the platform learns the intent model. The same pattern appears in recommendation systems (Netflix, Spotify) and fraud detection (Stripe, PayPal). It also appears in medical diagnosis support tools. In all these places, the "rules" are too complex for a human to write by hand. Yet patterns exist in data.

9.2 What Makes Good Code — Five Features for ML

9.2.1 Definition and Context

Good code is not just code that runs. It must fulfill functional requirements and non-functional requirements. Additional factors include: readability, meaningful names, modularity, adherence to standards (SOLID principles, single responsibility, cohesion, coupling), performance, maintainability, configurability, and proper error handling.

9.2.2 Simplicity — The DRY Principle

Where repetition happens in ML projects:

• Data preprocessing: code for cleaning data, handling missing values, scaling features — often repeated across experiments
• Feature engineering: same feature creation code used for multiple models (model 1, model 2, model 3)
• Model training: same training loops repeated
• Evaluation: same metrics computation repeated
• Prediction: same inference code repeated

Strategy for avoiding repetition:

• If a sequence of steps is repeated, abstract it as a function
• If a group of related functions is repeated, abstract it as a class
• If an entire pipeline (N sequential steps) is repeated, abstract it as a pipeline

# CSV 1
df1 = pd.read_csv("file1.csv")
df1 = df1.drop(["col_a", "col_b"], axis=1)
df1 = df1.set_index("id")

# CSV 2
df2 = pd.read_csv("file2.csv")
df2 = df2.drop(["col_a", "col_b"], axis=1)
df2 = df2.set_index("id")

# CSV 3
df3 = pd.read_csv("file3.csv")
df3 = df3.drop(["col_a", "col_b"], axis=1)
df3 = df3.set_index("id")

def load_and_clean(csv_file, columns_to_drop):
    df = pd.read_csv(csv_file)
    df = df.drop(columns_to_drop, axis=1)
    df = df.set_index("id")
    return df

df1 = load_and_clean("file1.csv", ["col_a", "col_b"])
df2 = load_and_clean("file2.csv", ["col_a", "col_b"])
df3 = load_and_clean("file3.csv", ["col_a", "col_b"])

Real-world example with AI-generated code: When using tools like ChatGPT or Claude to generate code for a data pipeline, give the entire requirement in one prompt. Include the instruction "use DRY principle." The result will be modularized code. Each preprocessing step (binning, cleaning, normalization, feature importance) becomes a separate .py file with a reusable function. A scheduler calls them sequentially. Adding a new step tomorrow only needs one new function and one registration. No duplication.

9.2.3 Modularity

This connects directly to the pipe-and-filter architectural pattern covered earlier — every filter is a module at some level of abstraction.

def load_data(csv_file):
    # Read and return raw data
    pass

def clean_data(input_data, max_length):
    # Remove noise, handle missing values
    pass

def plot_data(clean_data, x_axis_limit, line_width):
    # Visualize results
    pass

9.2.4 Readability

X = iris.data
Y = iris.target
m = DecisionTreeClassifier()
m.fit(X, Y)
p = m.predict(X)

training_data = iris.data
training_labels = iris.target
model = DecisionTreeClassifier()
model.fit(training_data, training_labels)
predictions = model.predict(training_data)

9.2.5 Performance

Code must execute in an optimized manner within a well-defined time. How to measure this is the main topic of sections 9.3–9.9. Performance includes both speed (execution time) and memory usage.

9.2.6 Robustness

Visual Intuition. Imagine a spectrum. On the left: a single 500-line Jupyter notebook with variables named x1, x2, temp, df3 — this is "bad code." On the right: modular .py files with descriptive names, each function testable in isolation — this is "good code." The five features are the qualities that move your code from left to right. The goal is not perfection — it is steady improvement.

Real-World & Domain Connection. The DRY principle is not just academic. At companies like Stripe and Netflix, ML pipelines process millions of transactions daily. A duplicated preprocessing step that goes out of sync with the canonical version can silently corrupt model inputs for weeks before anyone notices. Teams use tools like Prefect and MLflow to enforce pipeline modularity and track exactly which version of each preprocessing function was used for every model training run. This is DRY at organizational scale — one source of truth, not three divergent copies.

9.3 Performance Analysis — Overview

9.3.1 What We Measure

Performance in an ML system can be measured at two levels:

• End-to-end pipeline: from data collection to preprocessing to model training to evaluation — the entire ML workflow
• Individual component level: a single function, a single line of code, a single model training call

The goal is to find the bottleneck. When the system is slow, is it because of execution time (CPU-bound) or memory constraints (memory-bound)? Profiling answers this.

9.3.2 Ways to Make Python ML Code Faster

Real-World & Domain Connection. At Netflix, a recommendation model that takes 200 ms instead of 100 ms to return results affects millions of users simultaneously. The difference between a snappy UI and a sluggish one is often a single slow function that a profiler can identify in minutes. The tools in this lecture are the same ones used by production ML engineers at companies like Spotify, Stripe, and Google to keep their pipelines fast.

9.4 The time Module — Single-Run Timing

9.4.1 How It Works

The time module is Python's simplest way to measure how long a piece of code takes. The pattern:

import time

start_time = time.time()
# ... code to measure ...
end_time = time.time()
execution_time = end_time - start_time

It gives the wall-clock time for one execution. This is useful for measuring a single activity — training a model, preprocessing data, or the entire script.

9.4.2 Worked Example — Iris Dataset with Decision Tree

import time
from sklearn.datasets import load_iris
from sklearn.tree import DecisionTreeClassifier

# Load dataset
iris = load_iris()
X, y = iris.data, iris.target

# Time the training
start_time = time.time()
model = DecisionTreeClassifier()
model.fit(X, y)
end_time = time.time()

training_time = end_time - start_time
print(f"Training time: {training_time:.6f} seconds")

9.4.3 Limitations of the time Module

Real-World & Domain Connection. time.time() is commonly used in logging statements within production ML pipelines. Engineers sprinkle start = time.time() and elapsed = time.time() - start throughout their code to timestamp each stage of a pipeline (data load, preprocessing, inference). These timestamps feed into monitoring dashboards (Grafana, Datadog) that track pipeline health over days and weeks.

9.5 The timeit Module — Statistical Timing

9.5.1 Why timeit Is Better

The timeit module runs code multiple times and reports the average execution time along with the standard deviation. This gives a more reliable measurement because:

• Background process interference is averaged out
• You get a range (mean ± std dev), not just a single number
• Small standard deviation → consistent, stable performance
• Large standard deviation → inconsistent performance (possible CPU load, caching, or other issues to investigate)

9.5.2 Parameters: number and repeat

9.5.3 Worked Example — Iris Dataset with Decision Tree

import timeit
import statistics
from sklearn.datasets import load_iris
from sklearn.tree import DecisionTreeClassifier

def train_model():
    iris = load_iris()
    X, y = iris.data, iris.target
    model = DecisionTreeClassifier()
    model.fit(X, y)

# Benchmark: 100 calls per run, repeated 10 times
times = timeit.repeat(train_model, number=100, repeat=10)

# Average time per single call
avg_times = [t / 100 for t in times]
mean_time = statistics.mean(avg_times)
std_dev = statistics.stdev(avg_times)

print(f"Average training time: {mean_time:.6f} seconds")
print(f"Standard deviation:   {std_dev:.6f} seconds")

9.5.4 Using timeit in Google Colab / Jupyter Notebook

In Google Colab or any Jupyter Notebook (.ipynb), put %%timeit at the top of a cell:

%%timeit
# any code here
model = DecisionTreeClassifier()
model.fit(X, y)

This automatically runs the cell multiple times and reports the mean and standard deviation. Example output: 12.1 ms ± 3.64 ms per loop (mean ± std. dev. of 7 runs, 100 loops each).

9.5.5 time vs. timeit — Summary

Real-World & Domain Connection. Reliable benchmarking with timeit matters in ML model serving. When Stripe's fraud detection model serves predictions at 10,000 requests per second, a 1 ms slowdown per request means 10 seconds of cumulative delay per second. Engineers use timeit-style statistical benchmarking to ensure that model inference stays within strict latency SLAs (Service Level Agreements), typically measured at p99 (99th percentile) — which requires statistical distributions, not single measurements.

9.6 The cProfile Module — Function-Level Profiling

9.6.1 What Is a Profiler?

A profiler gives deeper performance insights than a timer. It tells you not just the total time, but which functions inside your code are fast and which are slow. The concept exists across domains — there are SQL profilers for databases, Java profilers, .NET profilers, and for Python: cProfile.

cProfile is called "C" profiler because it is a Python wrapper around a C-language profiling library (C is one of the fastest languages for execution). It is one of the most widely used profilers for Python applications.

9.6.2 What cProfile Shows

9.6.3 Worked Example — Iris Dataset with Random Forest

import cProfile
import pstats
from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier

def train_model():
    # 1. Load
    iris = load_iris()
    X, y = iris.data, iris.target
    # 2. Split
    X_train, X_test, y_train, y_test = train_test_split(
        X, y, test_size=0.3, random_state=42
    )
    # 3. Create model
    model = RandomForestClassifier(n_estimators=5, random_state=42)
    # 4. Train
    model.fit(X_train, y_train)
    # 5. Evaluate
    accuracy = model.score(X_test, y_test)
    return accuracy

# Profile
profiler = cProfile.Profile()
profiler.enable()
train_model()
profiler.disable()

# Print stats
stats = pstats.Stats(profiler)
stats.sort_stats('cumulative')
stats.print_stats()

9.6.4 When to Use cProfile

Real-World & Domain Connection. cProfile is the go-to first-pass profiler at companies like Instagram and Dropbox when debugging slow Python services. Engineers attach it to a running production process (with caution), capture a few seconds of profiling data, and immediately see which function is eating CPU cycles. Combined with visualization tools like SnakeViz (which renders cProfile output as interactive flame graphs), it becomes a powerful debugging tool for distributed systems.

9.7 The line_profiler Module — Line-Level Profiling

9.7.1 Installation and Purpose

Install via pip install line_profiler. It tells you how much time each individual line of a function takes, and what percentage of the total execution time each line consumes.

9.7.2 Worked Example — Same Iris + Random Forest Code

from line_profiler import LineProfiler
from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier

def train_model():
    iris = load_iris()                          # line 1
    X, y = iris.data, iris.target                # line 2
    X_train, X_test, y_train, y_test = (
        train_test_split(X, y, test_size=0.3, random_state=42)
    )                                            # line 3
    model = RandomForestClassifier(
        n_estimators=5, random_state=42
    )                                            # line 4
    model.fit(X_train, y_train)                  # line 5
    accuracy = model.score(X_test, y_test)       # line 6
    print(f"Accuracy: {accuracy:.4f}")           # line 7

profiler = LineProfiler()
profiler.add_function(train_model)
profiler.run('train_model()')
profiler.print_stats()

9.7.3 cProfile vs. line_profiler — When to Use Which

Real-World & Domain Connection. line_profiler is vital when debugging preprocessing pipelines. At Spotify, a feature engineering function normalizes audio features for millions of tracks. It might have 30 lines. line_profiler reveals that one list comprehension on line 17 causes 80% of the runtime. The fix is often one line: swap a Python loop for a vectorized NumPy operation. Without line_profiler, developers guess which line to optimize for hours.

9.8 Memory Profiling — Measuring Memory Usage

9.8.1 Two Libraries for Memory Profiling

The concept is the same across both — measure how much memory each line of code consumes. memray (developed by Bloomberg) also produces flamegraph visualizations for memory usage.

9.8.2 Memory Units

9.8.3 Worked Example — Same Iris + Random Forest Code

from memory_profiler import profile

@profile
def train_model():
    iris = load_iris()
    X, y = iris.data, iris.target
    X_train, X_test, y_train, y_test = train_test_split(
        X, y, test_size=0.3, random_state=42
    )
    model = RandomForestClassifier(n_estimators=5, random_state=42)
    model.fit(X_train, y_train)
    accuracy = model.score(X_test, y_test)
    print(f"Accuracy: {accuracy:.4f}")

train_model()

9.8.4 Why Memory Profiling Matters

9.8.5 Limitations in ML Code

Real-World & Domain Connection. Memory profiling is critical in edge deployment scenarios. When deploying ML models to mobile phones or IoT devices with 512 MB of RAM, every megabyte counts. TensorFlow Lite and ONNX Runtime use memory profiling data to decide which model architecture fits on-device. At Bloomberg, memray was developed specifically because their financial data processing pipelines were hitting memory limits on production servers — and existing Python memory profilers were not detailed enough to find the leaks.

9.9 Summary of Profiling Tools

9.9.1 Tool Comparison

9.9.2 Recommended Profiling Workflow

9.10 Student Questions and Answers

9.11 Key Industry Applications and Tools Mentioned

9.12 Exam and Assignment Guidance

• Assignment 1: Due date extended to July 7. Submit as a single PDF per group. Include code for ML components, screenshots of execution, and GR for ML diagrams (any tool or hand-drawn, with correct notation — ellipse, rectangle, etc.).
• Assignment 2 (upcoming): Will involve implementing the profiling techniques covered in this lecture — time, timeit, cProfile, line_profiler, memory_profiler — applied to your own domain, dataset, and problem statement. Expect to profile your ML pipeline, identify bottlenecks, and justify optimization decisions based on the profiling data.

• Textbook reference: The content of sessions 9, 10, and 11 is primarily from Textbook 2 (uploaded on the course platform) — Chapters 1 (What Is Good Code) and 2 (Analyzing Code Performance).
• Reference book: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (Prentice Hall) — soft copy available in course references. Pay special attention to chapters on naming, functions, and comments.

9.13 Key Takeaways

1. SE coding = explicit rules; ML coding = learned patterns from data. This fundamental difference affects debugging, quality measurement, and system design. In SE, you fix the code. In ML, the bug could be in the data, features, training process, OR code.
2. Five features of good ML code: simplicity (DRY — Don't Repeat Yourself), modularity (break into logical functions), readability (PEP 8 / Pylint), performance (time + memory), and robustness (error handling, reproducibility).
3. DRY principle: Abstract repeated logic into functions, classes, or pipelines. Data preprocessing, feature engineering, model training, and evaluation are common areas where repetition occurs. One canonical source of truth prevents divergent copies.
4. Pylint is a static code analyzer — checks style against PEP 8, suggests better names, flags unused imports and duplicate code, and verifies documentation — all without running the code.
5. Profiling hierarchy: time (single rough measurement) → timeit (statistical mean ± std dev) → cProfile (which function is slow?) → line_profiler (which line in that function?) → memory_profiler (how much RAM per line?).
6. timeit is more reliable than time because it averages multiple runs and reports standard deviation. Small std dev = consistent performance; large std dev = investigate.
7. model.fit is typically the bottleneck in ML code — and it is a library call you cannot rewrite. But you CAN choose a different algorithm, optimize data structures, use GPU acceleration, or restructure the surrounding pipeline.
8. Remove all profiling code before production. Profilers add 10–100× overhead. Use MLOps/LLMOps/AgentOps monitoring for live environments with minimal performance impact.
9. Accuracy is not the only selection criterion for ML algorithms — execution time and memory consumption matter equally in production. A slightly less accurate model that fits in your deployment budget is better than an accurate model that crashes.
10. Code generated by modern AI tools generally follows standards well — validate it with the same processes you use for human-written code (Pylint, SonarQube, manual review). Give complete requirements in one prompt and explicitly mention DRY for best results.