wt_status_collect_untracked() copies entries from dir.entries and dir.ignored into string_lists using string_list_insert(). That keeps the destination lists sorted and deduplicated, but each insertion may shift the backing array, making construction O(n^2) in the number of paths.

Collect the entries with string_list_append() instead, then sort and deduplicate each list once. This preserves the sorted, duplicate-free result while reducing the construction cost to O(n log n).

Signed-off-by: Sahitya Chandra <sahityajb@gmail.com>
---
Notes for reviewers:

fill_directory() currently sorts dir.entries and dir.ignored before returning, so another possible approach would be to append the entries directly and rely on that order, reducing this copy step to O(n). That would require relying on these arrays not containing duplicate entries, though, which I have not been able to verify yet. This patch takes the safer approach of preserving the existing duplicate-removal behavior from `string_list_insert()` by sorting and deduplicating once after appending.

 wt-status.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

On Fri, Jul 17, 2026 at 12:20:45AM +0530, Sahitya Chandra wrote:

Out of curiosity: is this something that you have encountered in the real world as inefficient, or is this rather a theoretical inefficiency? If the former it would be great to add a small benchmark to the commit message.

Instead of sorting and then deduplicating you can call `string_list_sort_u()`. It does the exact same thing as you do here, but I guess it makes sense to use that interface anyway.

Likewise.

Overall this looks like a sensible thing to do though. Thanks!

Patrick

On Fri, Jul 17, 2026 at 08:27:09AM +0200, Patrick Steinhardt wrote:

Yeah, I had the same question, and tried for a moment to produce an example before realizing that it probably is theoretical. If we are feeding the entries in pre-sorted order then the insert is always O(1).

I think it's still worth doing this, though, as it makes the result much more obvious to analyze. I think it could even be O(n) if the sort implementation is optimized under the hood for pre-sorted inputs.

-Peff

On Fri, Jul 17, 2026 at 11:57 AM Patrick Steinhardt <ps@pks.im> wrote:

Thanks for asking. I do not have a real-world benchmark for this. After Jeff's reply, I agree that the O(n^2) claim is too strong for the current code path because fill_directory() already returns the entries sorted, so string_list_insert() should usually append at the end.

I have reworded v2 to avoid that performance claim and describe the change as making the collection strategy explicit instead.

Done in v2. Thanks.

On Fri, Jul 17, 2026 at 1:24 PM Jeff King <peff@peff.net> wrote:

Thanks, that makes sense. I updated v2 to avoid claiming this is a current O(n^2) problem and instead frame it as making the append, sort, and deduplicate steps explicit.

I also switched to string_list_sort_u() as Patrick suggested.

wt_status_collect_untracked() copies entries from dir.entries and dir.ignored into string_lists using string_list_insert(). That keeps the destination lists sorted and deduplicated, but makes the code harder to reason about because it rebuilds sorted lists through repeated sorted insertion.

Collect the entries with string_list_append() instead, then sort and deduplicate each list once with string_list_sort_u(). This preserves the sorted, duplicate-free result while making the collection strategy explicit.

Signed-off-by: Sahitya Chandra <sahityajb@gmail.com>
---
Changes since v1:
- Use string_list_sort_u() instead of open-coding sort plus deduplication.
- Reword the subject and commit message to avoid overclaiming an O(n^2)
  cost when the input from fill_directory() is already sorted.

 wt-status.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

On Fri, Jul 17, 2026 at 08:16:20PM +0530, Sahitya Chandra wrote:

The patch looks good, and I think this explanation is OK-ish. But IMHO it is still worth talking about the quadratic issue, because that's really the motivation here (and what the "harder to reason about" is getting at).

So maybe something like:

  wt_status_collect_untracked() copies entries from dir.entries and
  dir.ignored into string_lists using string_list_insert(). At first
  glance this seems to be quadratic, because we may shift the backing
  array, incurring O(n) work for each insert.

  In practice, though, the entries in the dir struct are already sorted,
  so each we never have to shift the array (and only pay the log-n
  lookup cost for each insertion). But this is subtle and depends on the
  behavior of fill_directory().

  Collect the entries[...etc...]

?

-Peff

On Sat, Jul 18, 2026 at 1:01 PM Jeff King <peff@peff.net> wrote:

Thanks, that wording makes sense. I will use that structure in v3, and submit it right away :)

wt_status_collect_untracked() copies entries from dir.entries and dir.ignored into string_lists using string_list_insert(). At first glance this seems quadratic, because inserting into the sorted list may shift the backing array, incurring O(n) work for each insert.

In practice, though, the entries in the dir struct are already sorted, so we should not have to shift the array and only pay the O(log n) lookup cost for each insertion. But this is subtle and depends on the behavior of fill_directory().

Collect the entries with string_list_append() instead, then sort and deduplicate each list once with string_list_sort_u(). This preserves the sorted, duplicate-free result while making the collection strategy explicit.

Signed-off-by: Sahitya Chandra <sahityajb@gmail.com>
---
Changes since v2:
- Reword the commit message to explain the quadratic concern while noting
  that the current sorted input avoids array shifts in practice.

 wt-status.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

On Sat, Jul 18, 2026 at 01:44:49PM +0530, Sahitya Chandra wrote:

Looks good to me. ;)

-Peff