Skip to content
Back to Refactoring & Optimization

Performance Optimization (Rust)

Refactor Rust code to address inefficient algorithms and data structures.

Parameters

NameLabelRequiredDefault
codeCode to RefactorYes-
goalRefactoring GoalNo-

Prompt Template

You are a senior software engineer. Refactor the following Rust Actix code to address inefficient algorithms and data structures. Code: ```Rust {{code}} ``` Refactoring goal: {{goal}} Instructions: 1. Identify the specific inefficient algorithms and data structures in the code. 2. Apply the Performance Optimization refactoring technique step by step. 3. Preserve all existing behavior — the refactoring must be behavior-preserving. 4. Show the before and after for each step. 5. Explain the benefit of each change. 6. Note any tests that should be run to verify safety. Output: step-by-step refactoring with before/after and explanations.

Example

// Refactoring Rust Actix code: inefficient algorithms and data structures // Before: a 200-line function with nested conditionals // After: extracted into 3 focused methods with guard clauses // Benefit: each method is testable independently, complexity reduced // Safety: run existing unit tests — all must still pass

Tips

  • ✦Run the full test suite before and after refactoring — any failure means the refactoring changed behavior.
  • ✦Refactor in small, reviewable steps — large refactors hide bugs and are hard to review.
  • ✦Preserve the public API unless the goal explicitly includes API changes.

Why

According to the GitHub 2024 survey, 97% of developers use AI tools and AI-assisted refactoring reduces defect rates by 30% for inefficient algorithms and data structures. Performance Optimization improves code quality by addressing inefficient algorithms and data structures, making the code easier to maintain and extend. Cursor reports 18% of professional developers use AI refactoring daily, making structured refactoring a mainstream practice.

When

When code has inefficient algorithms and data structures that impedes readability, testability, or maintainability. Do not use this prompt when there are no passing tests or when the code is about to be deleted.

Common Problems

  • ⚠Error: test suite fails after refactoring — "3 tests failed: expected 5 but got 6". Fix: revert and redo in smaller steps, run tests after each step.
  • ⚠Error: no tests before refactoring — "cannot verify behavior preservation". Fix: write characterization tests first to capture current behavior.
  • ⚠Error: over-refactoring — "code is now more complex than original". Fix: stop when the code is good enough, perfect is the enemy of better.

Best Practices

  • ✓Always have passing tests before starting — tests are the refactoring safety net.
  • ✓Refactor in small commits, each behavior-preserving and independently revertable.
  • ✓Stop refactoring when the code is good enough — perfect is the enemy of better.

FAQ

What is this prompt for and why use it?

Refactor Rust code to address inefficient algorithms and data structures. According to the GitHub 2024 survey, 97% of developers use AI tools and AI-assisted refactoring reduces defect rates by 30% for inefficient algorithms and data structures. Performance Optimization improves code quality by addressing inefficient algorithms and

When should I use this prompt?

When code has inefficient algorithms and data structures that impedes readability, testability, or maintainability. Do not use this prompt when there are no passing tests or when the code is about to be deleted.

How do I get the best results with this prompt?

Key tips: Run the full test suite before and after refactoring — any failure means the refactoring changed behavior.; Refactor in small, reviewable steps — large refactors hide bugs and are hard to review.; Preserve the public API unless the goal explicitly includes API changes..

What common problems should I watch for?

Common problems: Error: test suite fails after refactoring — "3 tests failed: expected 5 but got 6". Fix: revert and redo in smaller steps, run tests after each step.; Error: no tests before refactoring — "cannot verify behavior preservation". Fix: write characterization tests first to capture current behavior.; Error: over-refactoring — "code is now more complex than original". Fix: stop when the code is good enough, perfect is the enemy of better..

What are the best practices?

Recommended: Always have passing tests before starting — tests are the refactoring safety net.; Refactor in small commits, each behavior-preserving and independently revertable.; Stop refactoring when the code is good enough — perfect is the enemy of better..