Will Rewriting a Slow Python Web Service in Rust Make It Faster?

Faster application code cannot erase unchanged waiting time

Rewriting a Python web service in Rust can improve response time only to the extent that it accelerates work on the request's path. If a substantial part is waiting for an unchanged external operation, that portion remains.

In his October 23 essay, engineer Sean Goedecke argues for profiling and redesign before asking AI to translate a program into a faster language. His example puts half a web request's time in database queries. That is an illustrative assumption, not a measured share for every service.

Suppose the original request takes 100ms, including 50ms of database waiting that the rewrite does not change:

This is arithmetic, not a Rust benchmark. Reducing queries or changing caching and concurrency can also reduce waiting, but then the fixed-wait assumption no longer holds. A rewrite that changes both language and design cannot attribute every gain to language execution speed.

Follow the slow request into its calls

Start with the request that is actually slow. Separate its overall latency from time spent in application functions and database or external API calls. Assuming a web service must be I/O-bound is no substitute for that measurement.

Python's deterministic profiler records function calls and timing. Internal time and cumulative time answer different questions: a function can have a high cumulative cost because it calls expensive work elsewhere.

Python 3.15 exposes this through profiling.tracing, with cProfile also available for compatibility. Recording calls introduces overhead. Use a profile to locate work, then compare the changed service under equivalent ordinary execution conditions as well.

The native function is only part of the cost

A concentrated CPU-heavy function may be a useful native-extension target without moving the entire application. The comparison must include moving data into and out of that function.

The PyO3 performance guide explains a concrete example: turning a Rust string into a Python string allocates a Python object. It provides interning for strings repeatedly reused at the same call site. Faster computation can still be accompanied by object-allocation overhead at the boundary.

Likewise, moving a Python wrapper does not automatically accelerate computation already performed by a native library or GPU. Distinguish a slow Python loop from expensive conversions and time inside an existing native operation.

Choose the change that reaches the bottleneck

The measured workload should determine the scope of a rewrite. These are practical starting points:

An AI task can begin with measuring a slow request and proposing a change to its dominant cost. Choose Rust when the proposed change addresses the measured problem. Afterward, compare both latency and output correctness with the same input and load.

FAQ