openai / openai/codex

apply_patch gets much slower when replacing thousands of lines in a large file

Open
#41,153 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug CLI performance tool-calls
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What happened

apply_patch gets disproportionately slow when it replaces thousands of lines near the beginning of a large text file. This adds avoidable latency to coding-agent turns that make large edits.

Using fixed-width text on Linux with an Intel Core Ultra 9 185H, the public apply-patch path produced these median timings for a 10 MiB file:

Replaced lines Median
1 22.34 ms
100 37.48 ms
1,000 163.8 ms
5,000 567 ms

The measured operation includes file I/O and patch processing. Fixture reset is excluded.

What I expected

Large replacements should be bounded mainly by reading and rewriting the file, rather than repeatedly shifting the in-memory line list for every removed or inserted line.

Any optimization should preserve patch matching and errors, LF normalization, trailing-newline behavior, exact line endings in preservation mode, and historical handling of overlapping EOF chunks in legacy mode.

Steps to reproduce

  1. Build the current apply_patch tool in release mode.
  2. Generate a 10 MiB LF text file containing fixed-width 96-byte lines.
  3. Apply one patch that replaces the first 1, 100, 1,000, or 5,000 lines with equal-width lines.
  4. Measure only the public patch operation, resetting the fixture outside the timed section.
  5. Compare how latency grows as the replacement size increases.

Additional context

The slowdown comes from removing and inserting lines individually, which shifts the remaining line list on each operation.

A one-pass proof of concept reduced the 1,000-line case from 163.8 ms to 23.77 ms and the 5,000-line case from 567 ms to 25.57 ms. The reference commit also contains the Divan benchmark and compatibility coverage:

https://github.com/HACKE-RC/codex/commit/c529be01d65d9f2e1e33f78a7e92ce204f5f821a

The proof was checked with the 101-test codex-apply-patch suite and the workspace benchmark smoke test. The synthetic benchmark isolates one contiguous replacement; it does not measure many independent hunks or concurrent writes.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the linked reference commit and the current public apply-patch implementation, then run the codex-apply-patch suite and workspace benchmark smoke test. Done means large contiguous replacements no longer scale with repeated line shifts while preserving patch matching, errors, newline behavior, preservation mode, and legacy overlapping EOF handling.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.