Skip to content

[WIP] perf(Core): tweak tryFindTextOfRange - #884

Draft
Numpsy wants to merge 1 commit into
fsprojects:masterfrom
Numpsy:tweak_test_of_range
Draft

[WIP] perf(Core): tweak tryFindTextOfRange#884
Numpsy wants to merge 1 commit into
fsprojects:masterfrom
Numpsy:tweak_test_of_range

Conversation

@Numpsy

@Numpsy Numpsy commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

tryFindTextOfRange appears to be a hotspot for performance in the current version (the calls to IndexOf show up at the top of profiles of the benchmark app)

So, I was wondering:

  • If the end position is always after the first, can we look for the end line starting from the start line, rather than searching from the start of the source text every time?
  • If the start and end positions are on the same line, it shouldn't need to do the 'find line' run twice
  • I don't think there is a need to look for the end index if it can't find the start, given that the function returns None if it can't get both

So - an attempt at a change

  • only look for the end position if we have the start
  • start looking for the end line starting at the offset of the start line, to reduce duplicate work (findLineStart should also then exit immediately if the start and end are on the same line)

tryFindTextOfRange appears to be a hotspot for performance in
the current version (the calls to IndexOf show up at the top of
profiles of the benchmark app)

So, I was wondering:
- If the end position is always after the first, can we look for the end line starting from the start line, rather than searching from the start of the source text every time?
- If the start and end positions are on the same line, it shouldn't need to do the 'find line' run twice
- I don't think there is a need to look for the end index if it can't find the start, given that the function returns None if it can't get both

So - an attempt at a change
- only look for the end position if we have the start
- start looking for the end line starting at the offset of the start line, to reduce duplicate work (findLineStart should also then exit immediately if the start and end are on the same line)
@Numpsy

Numpsy commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

A bit more musing based on this from profiling the benchmark app with the latest source:

image

If I run the benchmark of the current master branch with the default set of rules I get this now:


| Method         | Mean     | Error    | StdDev   | Gen0       | Gen1      | Gen2      | Allocated |
|--------------- |---------:|---------:|---------:|-----------:|----------:|----------:|----------:|
| LintParsedFile | 807.4 ms | 16.09 ms | 22.03 ms | 14000.0000 | 5000.0000 | 1000.0000 | 229.87 MB |

But with this change I get

| Method         | Mean     | Error   | StdDev  | Gen0       | Gen1      | Gen2      | Allocated |
|--------------- |---------:|--------:|--------:|-----------:|----------:|----------:|----------:|
| LintParsedFile | 476.1 ms | 6.95 ms | 5.81 ms | 14000.0000 | 5000.0000 | 1000.0000 | 229.87 MB |

with the changes from #877 and the extended set of rules from the self check I get this

| Method         | Mean    | Error    | StdDev   | Gen0       | Gen1      | Gen2      | Allocated |
|--------------- |--------:|---------:|---------:|-----------:|----------:|----------:|----------:|
| LintParsedFile | 2.132 s | 0.0148 s | 0.0139 s | 19000.0000 | 7000.0000 | 2000.0000 | 307.44 MB |

but with this change on top of that I get

| Method         | Mean    | Error    | StdDev   | Gen0       | Gen1      | Gen2      | Allocated |
|--------------- |--------:|---------:|---------:|-----------:|----------:|----------:|----------:|
| LintParsedFile | 1.333 s | 0.0112 s | 0.0100 s | 19000.0000 | 8000.0000 | 2000.0000 | 307.44 MB |

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant