git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] last-modified: implement faster algorithm

From
Toon Claes <toon@iotcl.com>
Date
Oct 17, 2025, 10:47 UTC
Message-ID
<87ms5pu7n6.fsf@iotcl.com>
In-Reply-To
<20251017063701.GA3091356@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 42 quoted lines
> On Thu, Oct 16, 2025 at 10:39:25AM +0200, Toon Claes wrote:
>
>> +	for (i = 0; i < diff_queued_diff.nr; i++) {
>> +		struct diff_filepair *fp = diff_queued_diff.queue[i];
>> +		size_t k = path_idx(lm, fp->two->path);
>> +		if (0 <= k && bitmap_get(active_c, k))
>> +			bitmap_set(lm->scratch, k);
>> +		diff_free_filepair(fp);
>> +	}
>
> Just one little oddity while looking at this versus the old patches from
> Taylor. Here you call diff_free_filepair(). But later...
>
>> +	diff_queued_diff.nr = 0;
>> +	diff_queue_clear(&diff_queued_diff);
>
> ...you call diff_queue_clear(), which frees the filepairs itself. It
> does the right thing, because you truncate the queue explicitly. But
> would it be simpler to just leave them in place and let the _clear()
> function clean up? I.e., this:
>
> diff --git a/builtin/last-modified.c b/builtin/last-modified.c
> index 40e520ba18..47f2b0ed44 100644
> --- a/builtin/last-modified.c
> +++ b/builtin/last-modified.c
> @@ -315,7 +315,6 @@ static void process_parent(struct last_modified *lm,
>  		size_t k = path_idx(lm, fp->two->path);
>  		if (0 <= k && bitmap_get(active_c, k))
>  			bitmap_set(lm->scratch, k);
> -		diff_free_filepair(fp);
>  	}
>  	for (i = 0; i < lm->all_paths_nr; i++) {
>  		if (bitmap_get(active_c, i) && !bitmap_get(lm->scratch, i))
> @@ -331,7 +330,6 @@ static void process_parent(struct last_modified *lm,
>  	}
>  
>  	memset(lm->scratch->words, 0x0, lm->scratch->word_alloc);
> -	diff_queued_diff.nr = 0;
>  	diff_queue_clear(&diff_queued_diff);
>  }
>
> which feels a lot more idiomatic to me.

Hah, yes. I think I ended up in this situation because initially I was only trying to fix memory leaks. Thanks, I will included these changes.

-- 
Cheers,
Toon
Previous: Jeff KingNext: Toon Claes
Message 17 of 39 in “last-modified: implement faster algorithm”
  1. last-modified: implement faster algorithmToon Claes, Oct 16, 2025
  2. Justin ToblerOct 16, 2025
  3. Toon ClaesOct 17, 2025
  4. D. Ben KnobleOct 16, 2025
  5. Toon ClaesOct 17, 2025
  6. Taylor BlauOct 16, 2025
  7. Jeff KingOct 17, 2025
  8. Taylor BlauOct 17, 2025
  9. Jeff KingOct 21, 2025
  10. Toon ClaesOct 17, 2025
  11. Toon ClaesOct 21, 2025
  12. Taylor BlauOct 23, 2025
  13. Toon ClaesOct 21, 2025
  14. Taylor BlauOct 23, 2025
  15. Toon ClaesOct 27, 2025
  16. Jeff KingOct 17, 2025
  17. Toon ClaesOct 17, 2025
  18. last-modified: implement faster algorithmToon Claes, Oct 21, 2025
  19. Junio C HamanoOct 21, 2025
  20. Taylor BlauOct 22, 2025
  21. Taylor BlauOct 22, 2025
  22. Junio C HamanoOct 22, 2025
  23. Taylor BlauOct 24, 2025
  24. Junio C HamanoOct 24, 2025
  25. Taylor BlauOct 27, 2025
  26. Toon ClaesOct 29, 2025
  27. Toon ClaesOct 23, 2025
  28. last-modified: implement faster algorithmToon Claes, Oct 23, 2025
  29. Taylor BlauOct 24, 2025
  30. Toon ClaesOct 27, 2025
  31. last-modified: implement faster algorithmToon Claes, Nov 3, 2025
  32. Junio C HamanoNov 3, 2025
  33. Toon ClaesNov 4, 2025
  34. t8020-last-modified.sh failure on s390x (Re: [PATCH v4] last-modified: implement faster algorithm)Anders Kaseorg, Nov 19, 2025
  35. Kristoffer HaugsbakkNov 19, 2025
  36. Anders KaseorgNov 19, 2025
  37. Jeff KingNov 20, 2025
  38. Toon ClaesNov 28, 2025
  39. Kristoffer HaugsbakkNov 28, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.