)]}'
{
  "commit": "13ab441fb40abffd9bb2a2ac32e1c69cba6c3198",
  "tree": "32c2a1ecd68449dd3a36c3685e8dc3a84dc0f734",
  "parents": [
    "de33cf88daf58cf8322867389afa9bcf3e377696"
  ],
  "author": {
    "name": "Simon Marchi",
    "email": "simon.marchi@polymtl.ca",
    "time": "Sun Feb 09 00:51:04 2025 -0500"
  },
  "committer": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Mon Feb 10 11:28:56 2025 -0500"
  },
  "message": "gdb/dwarf: create multiple cooked index shards when reading .debug_names\n\nNew in v2:\n\n - install address map in a single shard\n - update test gdb.mi/mi-sym-info.exp to cope with the fact that\n   different symbols could be returned when using --max-results\n\nWhen playing with the .debug_names reader, I noticed it was\nsignificantly slower than the DWARF scanner.  Using a \"performance\"\nbuild of GDB (with optimization, no runtime sanitizer enabled, etc), I\nmeasure with the following command on a rather large debug info file\n(~4 GB):\n\n    $ time ./gdb -q -nx --data-directory\u003ddata-directory \u003cbinary\u003e -iex \u0027maint set dwarf sync on\u0027 -batch\n\nThis measures the time it takes for GDB to build the cooked index (plus\nsome startup and exit overhead).  I have a version of the binary without\n.debug_names and a version with .debug_names added using gdb-add-index.\nThe results are:\n\n - without .debug_names: 7.5 seconds\n - with .debug_names: 24 seconds\n\nThis is a bit embarrassing, given that the purpose of .debug_names is to\naccelerate things :).  The reason is that the .debug_names processing is\nnot parallelized at all, while the DWARF scanner is heavily\nparallelized.\n\nThe process of creating the cooked index from .debug_names is roughly in\ntwo steps:\n\n 1. scanning of .debug_names and creation of cooked index entries (see\n    mapped_debug_names_reader::scan_all_names)\n 2. finalization of the index, name canonicalization and sorting of the\n    entries (see cooked_index::set_contents).\n\nThis patch grabs a low hanging fruit by creating multiple cooked index\nshards instead of a single one during step one.  Just doing this allows\nthe second step of the processing to be automatically parallelized, as\neach shard is sent to a separate thread to be finalized.\n\nWith this patch, I get:\n\n - without .debug_names: 7.5 seconds\n - with .debug_names: 9.7 seconds\n\nNot as fast as we\u0027d like, but it\u0027s an improvement.\n\nThe process of scanning .debug_names could also be parallelized to shave\noff a few seconds.  My profiling shows that out of those ~10 seconds of\nexcecution, about 6 are inside scan_all_names.  Assuming perfect\nparallelization with 8 threads, it means that at best we could shave\nabout 5 seconds from that time, which sounds interesting.  I gave it a\nshot, but it\u0027s a much more intrusive change, I\u0027m not sure if I will\nfinish it.\n\nThis patch caused some regressions in gdb.mi/mi-sym-info.exp with the\ncc-with-debug-names board, in the test about the `--max-results` switch.\nIt appears at this test is relying on the specific symbols returned when\nusing `--max-results`.  As far as I know, we don\u0027t guarantee which\nspecific symbols are returned, so any of the matching symbols could be\nreturned.\n\nThe round robin method used in this patch to assign index entries to\nshards ends up somewhat randomizing which CU gets expanded first during\nthe symbol search, and therefore which order they appear in the\nobjfile\u0027s CU list, and therefore which one gets searched first.\n\nI meditated on whether keeping compunits sorted within objfiles would\nhelp make things more stable and predictable.  It would somewhat, but it\nwouldn\u0027t remove all sources of randomness.  It would still possible for\na call to `expand_symtabs_matching` to stop on the first hit.  Which\ncompunit gets expanded then would still be dependent on the specific\n`quick_symbol_functions` internal details / implementation.\n\nCommit 5b99c5718f1c (\"[gdb/testsuite] Fix various issues in\ngdb.mi/mi-sym-info.exp\") had already started to make the test a bit more\nflexible in terms of which symbols it accepts, but with this patch, I\nthink it\u0027s possible to get wildly varying results.  I therefore modified\nthe test to count the number of returned symbols, but not expect any\nspecific symbol.\n\nChange-Id: Ifd39deb437781f72d224ec66daf6118830042941\nApproved-By: Tom Tromey \u003ctom@tromey.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "191e8243c2c6bb238bd61363a2e011843b717e77",
      "old_mode": 33188,
      "old_path": "gdb/dwarf2/cooked-index.h",
      "new_id": "8c2cc76fee15eaaca797d6310bf31fcf80a95f1e",
      "new_mode": 33188,
      "new_path": "gdb/dwarf2/cooked-index.h"
    },
    {
      "type": "modify",
      "old_id": "aeddab66b51938395b8ffd40e4a487d9b038d369",
      "old_mode": 33188,
      "old_path": "gdb/dwarf2/read-debug-names.c",
      "new_id": "fe31a58d743ea776cbee8f0e0b910edbbf401c34",
      "new_mode": 33188,
      "new_path": "gdb/dwarf2/read-debug-names.c"
    },
    {
      "type": "modify",
      "old_id": "b8db2af0d0ba4c1444da891824540fa4577a0405",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.mi/mi-sym-info.exp",
      "new_id": "47ca515956af6942cb6a640a3b498bad97a4fd1e",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.mi/mi-sym-info.exp"
    }
  ]
}