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

[RFC PATCH 0/2] merge-recursive: optimize time complexity

From
Meet Soni <meetsoni3017@gmail.com>
Date
Feb 13, 2025, 09:00 UTC
Message-ID
<20250213090040.16133-1-meetsoni3017@gmail.com>
In-Reply-To
<20250211194334.20710-1-meetsoni3017@gmail.com>
changes in this version:
    - Updated comment and commit message as per review.
    - Added another commit implementing optimization logic.
    - added an RFC tag since, if the changes in 2nd commit are
      appropriate, we can apply similar logic in other places as
      well.
Meet Soni (2):
  merge-recursive: optimize time complexity for process_renames
  merge-recursive: optimize time complexity for get_unmerged
 merge-recursive.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)
Range-diff:
1:  ec96e4010e ! 1:  c7dca6e971 merge-recursive: optimize string_list construction
    @@ Metadata
     Author: Meet Soni <meetsoni3017@gmail.com>
     
      ## Commit message ##
    -    merge-recursive: optimize string_list construction
    +    merge-recursive: optimize time complexity for process_renames
     
    -    Avoid O(n^2) complexity when building a sorted `string_list` by
    -    constructing it unsorted and sorting it afterward, reducing the
    -    complexity to O(n log n).
    +    Avoid O(n^2) complexity in `process_renames()` when building a sorted
    +    `string_list` by constructing it unsorted and sorting it afterward,
    +    reducing the complexity to O(n log n).
     
         Signed-off-by: Meet Soni <meetsoni3017@gmail.com>
     
      ## merge-recursive.c ##
     @@ merge-recursive.c: static int process_renames(struct merge_options *opt,
    - 	struct string_list b_by_dst = STRING_LIST_INIT_NODUP;
      	const struct rename *sre;
      
    --	/*
    + 	/*
     -	 * FIXME: As string-list.h notes, it's O(n^2) to build a sorted
     -	 * string_list one-by-one, but O(n log n) to build it unsorted and
     -	 * then sort it.  Note that as we build the list, we do not need to
     -	 * check if the existing destination path is already in the list,
     -	 * because the structure of diffcore_rename guarantees we won't
     -	 * have duplicates.
    --	 */
    ++	 * Note that as we build the list, we do not need to check if the
    ++	 * existing destination path is already in the list, because the
    ++	 * structure of diffcore_rename guarantees we won't have duplicates.
    + 	 */
      	for (i = 0; i < a_renames->nr; i++) {
      		sre = a_renames->items[i].util;
     -		string_list_insert(&a_by_dst, sre->pair->two->path)->util
-:  ---------- > 2:  78a007be7d merge-recursive: optimize time complexity for get_unmerged
-- 
2.34.1
Previous: Elijah NewrenNext: Meet Soni
Message 3 of 17 in “merge-recursive: optimize string_list construction”
  1. Meet SoniFeb 11, 2025
  2. Elijah NewrenFeb 11, 2025
  3. 0/2 merge-recursive: optimize time complexityMeet Soni, Feb 13, 2025
  4. 1/2 merge-recursive: optimize time complexity for process_renamesMeet Soni, Feb 13, 2025
  5. Elijah NewrenFeb 13, 2025
  6. 2/2 merge-recursive: optimize time complexity for get_unmergedMeet Soni, Feb 13, 2025
  7. Elijah NewrenFeb 13, 2025
  8. Junio C HamanoFeb 13, 2025
  9. Elijah NewrenFeb 13, 2025
  10. Meet SoniFeb 14, 2025
  11. Elijah NewrenFeb 14, 2025
  12. Meet SoniFeb 14, 2025
  13. Elijah NewrenFeb 14, 2025
  14. Meet SoniFeb 15, 2025
  15. Meet SoniFeb 13, 2025
  16. Elijah NewrenFeb 13, 2025
  17. [GSoC][PATCH v2] merge-recursive: optimize time complexity for process_renamesMeet Soni, Feb 14, 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.