perf: only compute start offset for overlong lines

[sbrugman]

Moves the computation of the start_offset for overlong lines to just before the result is returned. There is a slight overhead for overlong lines (double the work for the first limit characters).

In practice this results in a speedup on the CPython codebase. Most lines are not overlong, or are not enforced because the line ends with a URL, or does not contain whitespace. Nonetheless, the 0.3% of overlong lines are a lot compared to other violations.

Before

Selected W505 and E501

All rules

After

Selected W505 and E501

All rules

CPython line statistics:

• Number of Python lines: 867.696
• Number of overlong lines: 2.963 (0.3%)

Benchmark selected:

cargo build --release && hyperfine --warmup 10 --min-runs 50 \                                                  
  "./target/release/ruff ./crates/ruff/resources/test/cpython/ --no-cache -e --select W505,E501"

Benchmark all:

cargo build --release && hyperfine --warmup 10 --min-runs 50 \                                                  
  "./target/release/ruff ./crates/ruff/resources/test/cpython/ --no-cache -e --select ALL"

Overlong lines in CPython

cargo run -p ruff_cli -- check crates/ruff/resources/test/cpython/Lib --no-cache --select=E501,W505 --statistics

Total Python lines:

find crates/ruff/resources/test/cpython/ -name '*.py' | xargs wc -l

(Performance tested on Mac M1)

[konstin]

amazing, that's a neat speedup

[charliermarsh]

That’s awesome. I’m wondering if there’s another optimization we can make here. Is it faster to compute the number of bytes in the line instead of the width? If so, could we only check lines that have more bytes than the line limit? I think it would be impossible for an overlong line to have fewer bytes than the limit, though lines with more bytes could end up being below the limit.

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.00      9.7±0.02ms     4.2 MB/sec    1.01      9.8±0.03ms     4.1 MB/sec
formatter/numpy/ctypeslib.py               1.00   1873.7±1.81µs     8.9 MB/sec    1.01  1899.6±11.00µs     8.8 MB/sec
formatter/numpy/globals.py                 1.00    204.2±0.38µs    14.5 MB/sec    1.02    208.0±2.20µs    14.2 MB/sec
formatter/pydantic/types.py                1.00      4.2±0.01ms     6.1 MB/sec    1.01      4.3±0.04ms     6.0 MB/sec
linter/all-rules/large/dataset.py          1.01     13.7±0.02ms     3.0 MB/sec    1.00     13.6±0.02ms     3.0 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.02      3.5±0.01ms     4.7 MB/sec    1.00      3.5±0.01ms     4.8 MB/sec
linter/all-rules/numpy/globals.py          1.04    385.1±0.62µs     7.7 MB/sec    1.00    370.9±1.48µs     8.0 MB/sec
linter/all-rules/pydantic/types.py         1.01      6.2±0.01ms     4.1 MB/sec    1.00      6.1±0.01ms     4.2 MB/sec
linter/default-rules/large/dataset.py      1.02      7.0±0.02ms     5.8 MB/sec    1.00      6.9±0.01ms     5.9 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.04   1465.6±3.12µs    11.4 MB/sec    1.00   1410.7±2.05µs    11.8 MB/sec
linter/default-rules/numpy/globals.py      1.08    159.8±0.56µs    18.5 MB/sec    1.00    147.9±0.27µs    19.9 MB/sec
linter/default-rules/pydantic/types.py     1.03      3.2±0.01ms     8.1 MB/sec    1.00      3.1±0.01ms     8.3 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.04     11.3±0.09ms     3.6 MB/sec    1.00     10.9±0.08ms     3.7 MB/sec
formatter/numpy/ctypeslib.py               1.03      2.2±0.04ms     7.5 MB/sec    1.00      2.2±0.04ms     7.7 MB/sec
formatter/numpy/globals.py                 1.03   253.0±24.74µs    11.7 MB/sec    1.00    245.4±5.50µs    12.0 MB/sec
formatter/pydantic/types.py                1.03      4.8±0.05ms     5.3 MB/sec    1.00      4.7±0.06ms     5.4 MB/sec
linter/all-rules/large/dataset.py          1.02     15.4±0.13ms     2.6 MB/sec    1.00     15.1±0.13ms     2.7 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.02      4.1±0.04ms     4.1 MB/sec    1.00      4.0±0.05ms     4.2 MB/sec
linter/all-rules/numpy/globals.py          1.03    500.9±6.14µs     5.9 MB/sec    1.00    486.8±5.58µs     6.1 MB/sec
linter/all-rules/pydantic/types.py         1.02      7.0±0.06ms     3.7 MB/sec    1.00      6.8±0.05ms     3.7 MB/sec
linter/default-rules/large/dataset.py      1.03      8.0±0.05ms     5.1 MB/sec    1.00      7.8±0.04ms     5.2 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.06  1720.4±15.74µs     9.7 MB/sec    1.00  1628.4±12.98µs    10.2 MB/sec
linter/default-rules/numpy/globals.py      1.07    201.3±2.45µs    14.7 MB/sec    1.00    187.3±2.52µs    15.8 MB/sec
linter/default-rules/pydantic/types.py     1.03      3.6±0.03ms     7.1 MB/sec    1.00      3.5±0.03ms     7.3 MB/sec

[MichaReiser]

That’s awesome. I’m wondering if there’s another optimization we can make here. Is it faster to compute the number of bytes in the line instead of the width? If so, could we only check lines that have more bytes than the line limit? I think it would be impossible for an overlong line to have fewer bytes than the limit, though lines with more bytes could end up being below the limit.

That sounds like a neat optimization. Each character is between 1-4 bytes. Meaning your assumption here is safe.

Checking the byte length is O(1)

[sbrugman]

Selected

All