⚡️ Speed up method FastMCP.get_context by 56%
#9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📄 56% (0.56x) speedup for
FastMCP.get_contextinsrc/mcp/server/fastmcp/server.py⏱️ Runtime :
89.8 microseconds→57.7 microseconds(best of857runs)📝 Explanation and details
Here’s how to make this program run faster, especially focusing on the get_context method, which is responsible for the overwhelming majority of time spent (94%+) instantiating the
Contextobject. Since you cannot modifyContextitself (not given in the code), but instantiation dominates cost, object re-use with caching (if possible) and local variable lookups will not help (because construction is always needed and we're providing different args each time).Minimally you can use
__slots__for your own new helper classes if any, but since the true bottleneck isContext(...), the only effective optimization is to minimize unnecessary work:Context.Since the rest of the FastMCP
__init__logic is one-time setup and I/O-bound (handlers, logging), it can't be further optimized.You can optimize
get_contextby using a cached empty context if and only if there’s no request context (ie, in the exception case), so as to avoid constructing a newContextobject every time when it would always be identical.Below is a faster version.
Key optimization:
Contextwhen there is no request context, eliminating repeated construction of identical objects in the cold path.This is the fastest variant possible without changing the Context implementation itself.
If you later profile and find
Contextconstruction dominates even on the hot path, you’d need to optimize theContextclass itself or supply a context pool, which is not possible given your constraints.All variable and handler setup is already optimal.
✅ Correctness verification report:
🌀 Generated Regression Tests Details
To edit these changes
git checkout codeflash/optimize-FastMCP.get_context-ma311uxband push.