{"thread":{"id":"51068","subject":"I made a flame graph renderer for git's trace2 output","startedAt":"2019-05-10T15:10:04Z","lastAt":"2019-05-21T20:46:21Z","messageCount":9,"participants":["Ævar Arnfjörð Bjarmason","Derrick Stolee","SZEDER Gábor","Jeff King","Jeff Hostetler"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"375299","messageId":"87zhnuwdkp.fsf@evledraar.gmail.com","threadId":"51068","inReplyTo":null,"subject":"I made a flame graph renderer for git's trace2 output","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-10T15:09:58Z","receivedAt":"2019-05-10T15:10:04Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Here's a flamegraph of where git's test suite spends its time on my box:\nhttps://vm.nix.is/~avar/noindex/git-tests.svg\n\nI hacked up a script for this today to plot trace2 production data, as\nnoted there it's at:\nhttps://github.com/avar/FlameGraph/tree/stackcollapse-git-tr2-event\n\nWhat are flamegraphs? See http://www.brendangregg.com/flamegraphs.html\n\nAs noted in TODOs in the script there's various stuff I'd like to do\nbetter, and this also shows how we need a lot more trace regions to get\ngranular data.\n\nBut it's already quite cool, and I'll keep improving it. I'll submit a\nPR to Brendan's parent repo once I'm happy enough with it, I figure it\nmakes more sense there than in git.git, but maybe we'd eventually want\nto teach the test suite to optionally use something like this.\n"},{"id":"375303","messageId":"8794fd2e-6256-3238-6d87-2e726d4a91fa@gmail.com","threadId":"51068","inReplyTo":"87zhnuwdkp.fsf@evledraar.gmail.com","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-05-10T16:38:52Z","receivedAt":"2019-05-10T16:38:57Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 5/10/2019 11:09 AM, Ævar Arnfjörð Bjarmason wrote:\n> Here's a flamegraph of where git's test suite spends its time on my box:\n> https://vm.nix.is/~avar/noindex/git-tests.svg\n> \n> I hacked up a script for this today to plot trace2 production data, as\n> noted there it's at:\n> https://github.com/avar/FlameGraph/tree/stackcollapse-git-tr2-event\n> \n> What are flamegraphs? See http://www.brendangregg.com/flamegraphs.html\n> \n> As noted in TODOs in the script there's various stuff I'd like to do\n> better, and this also shows how we need a lot more trace regions to get\n> granular data.\n> \n> But it's already quite cool, and I'll keep improving it. I'll submit a\n> PR to Brendan's parent repo once I'm happy enough with it, I figure it\n> makes more sense there than in git.git, but maybe we'd eventually want\n> to teach the test suite to optionally use something like this.\n\nThis is a neat idea. Thanks!\n\nFor anyone else giving this a try, here are the steps I took to create\nmy own [1], much smaller test:\n\n# run some tests\nexport GIT_TR2_EVENT=~/git-tr2-event.txt\ngit fetch --all\ngit gc\ngit push\n\n# get the FlameGraph repo\ngit clone https://github.com/avar/FlameGraph.git\ncd FlameGraph\n\n(\n    # Get the proper perl packages, if you don't have them\n    sudo apt install cpanminus\n    sudo cpanm install JSON::XS\n)\n\n./stackcollapse-git-tr2-event.pl ~/git-tr2-event.txt | ./flamegraph.pl >git-test.svg\n\n\n[1] https://github.com/derrickstolee/FlameGraph/blob/git-test/git-test.svg\n"},{"id":"375305","messageId":"20190510170014.GQ14763@szeder.dev","threadId":"51068","inReplyTo":"8794fd2e-6256-3238-6d87-2e726d4a91fa@gmail.com","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-05-10T17:00:14Z","receivedAt":"2019-05-10T17:00:20Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, May 10, 2019 at 12:38:52PM -0400, Derrick Stolee wrote:\n> export GIT_TR2_EVENT=~/git-tr2-event.txt\n\nHrm,  better late than never, or at least better late than after it's\nin a release...\n\nWhy does an environment variable that is supposed to be set by users\nhave this \"TR2\" abbreviation in its prefix?  What exactly, if\nanything, did we gain by omitting \"ACE\" and not calling it\n\"GIT_TRACE2_...\"?\n\nKen Thompson springs to mind, who (allegedly?) later regretted\nspelling creat()/O_CREAT without the 'e'...\n\n"},{"id":"375323","messageId":"20190510210324.GA30947@sigill.intra.peff.net","threadId":"51068","inReplyTo":"87zhnuwdkp.fsf@evledraar.gmail.com","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-05-10T21:03:24Z","receivedAt":"2019-05-10T21:03:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> As noted in TODOs in the script there's various stuff I'd like to do\n> better, and this also shows how we need a lot more trace regions to get\n> granular data.\n\nHmm. My gut reaction was: doesn't \"perf record -g make test\" already\ngive us that granular data? I know \"perf\" isn't available everywhere,\nbut the idea of the FlameGraph repo is that it takes input from a lot of\nsources (though I don't know if it supports any Windows-specific formats\nyet, which is presumably a point of interesting to trace-2 authors).\n\nBut having generated such a flamegraph, it's not all that helpful. It\nmainly tells us that we spend a lot of time on fork/exec. Which is no\nsurprise, since the test suite is geared not towards heavy workloads,\nbut lots of tiny functionality tests.\n\nTBH, I'm not sure that flame-graphing the test suite is going to be all\nthat useful in the long run. It's going to be heavily weighted by the\ntypes of things the test suite does. Flamegraphs are good for\nunderstanding where your time is going for a particular workload, but\nthe workload of the test suite is not that interesting.\n\nAnd once you do have a particular workload of interest that you can\nreplay, then I think the granular \"perf\" results really can be helpful.\n\nI think the trace2 flamegraph would be most useful if you were\ncollecting across a broad spectrum of workloads done by a user. You\n_can_ do that with perf or similar tools, but it can be a bit awkward.\nI do wonder how painful it would be to alias \"git\" to \"perf record git\"\nfor a day or something.\n\n-Peff\n"},{"id":"375326","messageId":"87y33evuop.fsf@evledraar.gmail.com","threadId":"51068","inReplyTo":"20190510210324.GA30947@sigill.intra.peff.net","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-10T21:57:58Z","receivedAt":"2019-05-10T21:58:04Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, May 10 2019, Jeff King wrote:\n\n> On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> As noted in TODOs in the script there's various stuff I'd like to do\n>> better, and this also shows how we need a lot more trace regions to get\n>> granular data.\n>\n> Hmm. My gut reaction was: doesn't \"perf record -g make test\" already\n> give us that granular data? I know \"perf\" isn't available everywhere,\n> but the idea of the FlameGraph repo is that it takes input from a lot of\n> sources (though I don't know if it supports any Windows-specific formats\n> yet, which is presumably a point of interesting to trace-2 authors).\n>\n> But having generated such a flamegraph, it's not all that helpful. It\n> mainly tells us that we spend a lot of time on fork/exec. Which is no\n> surprise, since the test suite is geared not towards heavy workloads,\n> but lots of tiny functionality tests.\n>\n> TBH, I'm not sure that flame-graphing the test suite is going to be all\n> that useful in the long run. It's going to be heavily weighted by the\n> types of things the test suite does. Flamegraphs are good for\n> understanding where your time is going for a particular workload, but\n> the workload of the test suite is not that interesting.\n>\n> And once you do have a particular workload of interest that you can\n> replay, then I think the granular \"perf\" results really can be helpful.\n>\n> I think the trace2 flamegraph would be most useful if you were\n> collecting across a broad spectrum of workloads done by a user. You\n> _can_ do that with perf or similar tools, but it can be a bit awkward.\n> I do wonder how painful it would be to alias \"git\" to \"perf record git\"\n> for a day or something.\n\nYeah I should have mentioned that I'm mainly linking to the test suite\nrendering as a demo.\n\nMy actual use-case for this is to see what production nodes are spending\ntheir time on, similar to what Microsoft is doing with their use of this\nfacility.\n\nThe test suite serves as a really good test-case for the output, and to\nstress-test my aggregation script, since we're pretty much guaranteed to\nrun all our commands, and cover a lot of unusual cases.\n\nIt also shows that we've got a long way to go in improving the trace2\nfacility, i.e. adding region enter/leave for some of the things we spend\nthe most time on.\n"},{"id":"375944","messageId":"d1f9a2f4-500d-d5f6-af3d-75d3fdb1323b@jeffhostetler.com","threadId":"51068","inReplyTo":"87y33evuop.fsf@evledraar.gmail.com","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2019-05-20T18:22:25Z","receivedAt":"2019-05-20T18:22:30Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 5/10/2019 5:57 PM, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Fri, May 10 2019, Jeff King wrote:\n> \n>> On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>\n>>> As noted in TODOs in the script there's various stuff I'd like to do\n>>> better, and this also shows how we need a lot more trace regions to get\n>>> granular data.\n>>\n>> Hmm. My gut reaction was: doesn't \"perf record -g make test\" already\n>> give us that granular data? I know \"perf\" isn't available everywhere,\n>> but the idea of the FlameGraph repo is that it takes input from a lot of\n>> sources (though I don't know if it supports any Windows-specific formats\n>> yet, which is presumably a point of interesting to trace-2 authors).\n>>\n>> But having generated such a flamegraph, it's not all that helpful. It\n>> mainly tells us that we spend a lot of time on fork/exec. Which is no\n>> surprise, since the test suite is geared not towards heavy workloads,\n>> but lots of tiny functionality tests.\n>>\n>> TBH, I'm not sure that flame-graphing the test suite is going to be all\n>> that useful in the long run. It's going to be heavily weighted by the\n>> types of things the test suite does. Flamegraphs are good for\n>> understanding where your time is going for a particular workload, but\n>> the workload of the test suite is not that interesting.\n>>\n>> And once you do have a particular workload of interest that you can\n>> replay, then I think the granular \"perf\" results really can be helpful.\n>>\n>> I think the trace2 flamegraph would be most useful if you were\n>> collecting across a broad spectrum of workloads done by a user. You\n>> _can_ do that with perf or similar tools, but it can be a bit awkward.\n>> I do wonder how painful it would be to alias \"git\" to \"perf record git\"\n>> for a day or something.\n> \n> Yeah I should have mentioned that I'm mainly linking to the test suite\n> rendering as a demo.\n> \n> My actual use-case for this is to see what production nodes are spending\n> their time on, similar to what Microsoft is doing with their use of this\n> facility.\n> \n> The test suite serves as a really good test-case for the output, and to\n> stress-test my aggregation script, since we're pretty much guaranteed to\n> run all our commands, and cover a lot of unusual cases.\n> \n> It also shows that we've got a long way to go in improving the trace2\n> facility, i.e. adding region enter/leave for some of the things we spend\n> the most time on.\n> \n\nVery nice!\n\nYes, there is more work to do to add more regions to get more\ngranular data for interesting/problematic things.  My primary\ngoal in this phase has been to get the basic machinery in place\nand be vetted with some universally interesting regions, such as\nreading/writing the index and the phases of status.\n\nGoing forward, we can trivially (permanently) add new regions as we\nwant.  I tend to use temporary \"experimental\" regions during my perf\ninvestigations so that I don't clutter up the mainline source with\nuninteresting noise.\n\nWRT the TODO's in your script:\n\n[] I don't think data events will be useful for your usage.  The data\nvalues are orthogonal to the time values.\n\n[] I would add the child_start/_exit events to the stack.  This will\ngive you the names of non-builtin/shell commands and hooks.  The\nvarious \"child_class\" and \"use_shell\" and \"hook_name\" fields will help\nyou avoid duplicate stack frames (which you'll get for builtin\ncommands).\n\nJeff\n"},{"id":"375948","messageId":"0c3e48e0-ef87-39c2-a984-ba7deede0651@jeffhostetler.com","threadId":"51068","inReplyTo":"20190510170014.GQ14763@szeder.dev","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2019-05-20T18:49:26Z","receivedAt":"2019-05-20T18:50:13Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 5/10/2019 1:00 PM, SZEDER Gábor wrote:\n> On Fri, May 10, 2019 at 12:38:52PM -0400, Derrick Stolee wrote:\n>> export GIT_TR2_EVENT=~/git-tr2-event.txt\n> \n> Hrm,  better late than never, or at least better late than after it's\n> in a release...\n> \n> Why does an environment variable that is supposed to be set by users\n> have this \"TR2\" abbreviation in its prefix?  What exactly, if\n> anything, did we gain by omitting \"ACE\" and not calling it\n> \"GIT_TRACE2_...\"?\n> \n> Ken Thompson springs to mind, who (allegedly?) later regretted\n> spelling creat()/O_CREAT without the 'e'...\n> \n\nFor closure here on this thread.  I chose TR2 rather than TRACE2\nsomewhat at random for convenience during testing.  Changing is fine\nas you suggest in your other patch series.\n\nThanks\nJeff\n"},{"id":"375998","messageId":"877eajvqjm.fsf@evledraar.gmail.com","threadId":"51068","inReplyTo":"d1f9a2f4-500d-d5f6-af3d-75d3fdb1323b@jeffhostetler.com","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-21T14:19:09Z","receivedAt":"2019-05-21T14:19:15Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, May 20 2019, Jeff Hostetler wrote:\n\n> On 5/10/2019 5:57 PM, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> On Fri, May 10 2019, Jeff King wrote:\n>>\n>>> On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>>\n>>>> As noted in TODOs in the script there's various stuff I'd like to do\n>>>> better, and this also shows how we need a lot more trace regions to get\n>>>> granular data.\n>>>\n>>> Hmm. My gut reaction was: doesn't \"perf record -g make test\" already\n>>> give us that granular data? I know \"perf\" isn't available everywhere,\n>>> but the idea of the FlameGraph repo is that it takes input from a lot of\n>>> sources (though I don't know if it supports any Windows-specific formats\n>>> yet, which is presumably a point of interesting to trace-2 authors).\n>>>\n>>> But having generated such a flamegraph, it's not all that helpful. It\n>>> mainly tells us that we spend a lot of time on fork/exec. Which is no\n>>> surprise, since the test suite is geared not towards heavy workloads,\n>>> but lots of tiny functionality tests.\n>>>\n>>> TBH, I'm not sure that flame-graphing the test suite is going to be all\n>>> that useful in the long run. It's going to be heavily weighted by the\n>>> types of things the test suite does. Flamegraphs are good for\n>>> understanding where your time is going for a particular workload, but\n>>> the workload of the test suite is not that interesting.\n>>>\n>>> And once you do have a particular workload of interest that you can\n>>> replay, then I think the granular \"perf\" results really can be helpful.\n>>>\n>>> I think the trace2 flamegraph would be most useful if you were\n>>> collecting across a broad spectrum of workloads done by a user. You\n>>> _can_ do that with perf or similar tools, but it can be a bit awkward.\n>>> I do wonder how painful it would be to alias \"git\" to \"perf record git\"\n>>> for a day or something.\n>>\n>> Yeah I should have mentioned that I'm mainly linking to the test suite\n>> rendering as a demo.\n>>\n>> My actual use-case for this is to see what production nodes are spending\n>> their time on, similar to what Microsoft is doing with their use of this\n>> facility.\n>>\n>> The test suite serves as a really good test-case for the output, and to\n>> stress-test my aggregation script, since we're pretty much guaranteed to\n>> run all our commands, and cover a lot of unusual cases.\n>>\n>> It also shows that we've got a long way to go in improving the trace2\n>> facility, i.e. adding region enter/leave for some of the things we spend\n>> the most time on.\n>>\n>\n> Very nice!\n>\n> Yes, there is more work to do to add more regions to get more\n> granular data for interesting/problematic things.  My primary\n> goal in this phase has been to get the basic machinery in place\n> and be vetted with some universally interesting regions, such as\n> reading/writing the index and the phases of status.\n>\n> Going forward, we can trivially (permanently) add new regions as we\n> want.  I tend to use temporary \"experimental\" regions during my perf\n> investigations so that I don't clutter up the mainline source with\n> uninteresting noise.\n\nIndeed, a lot more regions are needed.\n\n> WRT the TODO's in your script:\n>\n> [] I don't think data events will be useful for your usage.  The data\n> values are orthogonal to the time values.\n\nI haven't done this, so I'm not asserting that it's useful, but from\nsome brief grepping a few datapoints are overwhelmingly common, and can\nbe faked up into regions of sorts for the purposes of a flamegraph.\n\nE.g. \"git checkout\" will reliably have read/version early on, and then\nwrite/version, in that case mostly/entirely redundant to the\ndo_{read,write}_index region, but in general I think we'll be able to\nloosely plot data points say as \"given the median runtime, here's the\nmedian % of time into the command we first encounter this data point\".\n\n> [] I would add the child_start/_exit events to the stack.  This will\n> give you the names of non-builtin/shell commands and hooks.  The\n> various \"child_class\" and \"use_shell\" and \"hook_name\" fields will help\n> you avoid duplicate stack frames (which you'll get for builtin\n> commands).\n\nYeah that's very useful. Any reason not to do something like this:\n\n    diff --git a/git.c b/git.c\n    index 1bf9c94550..6c926ae013 100644\n    --- a/git.c\n    +++ b/git.c\n    @@ -698 +698 @@ static void execv_dashed_external(const char **argv)\n    -       trace2_cmd_name(\"_run_dashed_\");\n    +       trace2_cmd_name(is_builtin(argv[0]) ? argv[0] : \"_run_dashed_\");\n\nI haven't tested, but we e.g. report 'git-submodule' as just\n'_run_dashed_', seems we could do better...\n"},{"id":"376013","messageId":"05486c53-ddea-b4e6-45b2-7365c8bc041c@jeffhostetler.com","threadId":"51068","inReplyTo":"877eajvqjm.fsf@evledraar.gmail.com","subject":"Re: I made a flame graph renderer for git's trace2 output","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2019-05-21T20:46:17Z","receivedAt":"2019-05-21T20:46:21Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 5/21/2019 10:19 AM, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Mon, May 20 2019, Jeff Hostetler wrote:\n> \n>> On 5/10/2019 5:57 PM, Ævar Arnfjörð Bjarmason wrote:\n>>>\n>>> On Fri, May 10 2019, Jeff King wrote:\n>>>\n>>>> On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>>>\n>>>>> As noted in TODOs in the script there's various stuff I'd like to do\n>>>>> better, and this also shows how we need a lot more trace regions to get\n>>>>> granular data.\n>>>>\n>>>> Hmm. My gut reaction was: doesn't \"perf record -g make test\" already\n>>>> give us that granular data? I know \"perf\" isn't available everywhere,\n>>>> but the idea of the FlameGraph repo is that it takes input from a lot of\n>>>> sources (though I don't know if it supports any Windows-specific formats\n>>>> yet, which is presumably a point of interesting to trace-2 authors).\n>>>>\n>>>> But having generated such a flamegraph, it's not all that helpful. It\n>>>> mainly tells us that we spend a lot of time on fork/exec. Which is no\n>>>> surprise, since the test suite is geared not towards heavy workloads,\n>>>> but lots of tiny functionality tests.\n>>>>\n>>>> TBH, I'm not sure that flame-graphing the test suite is going to be all\n>>>> that useful in the long run. It's going to be heavily weighted by the\n>>>> types of things the test suite does. Flamegraphs are good for\n>>>> understanding where your time is going for a particular workload, but\n>>>> the workload of the test suite is not that interesting.\n>>>>\n>>>> And once you do have a particular workload of interest that you can\n>>>> replay, then I think the granular \"perf\" results really can be helpful.\n>>>>\n>>>> I think the trace2 flamegraph would be most useful if you were\n>>>> collecting across a broad spectrum of workloads done by a user. You\n>>>> _can_ do that with perf or similar tools, but it can be a bit awkward.\n>>>> I do wonder how painful it would be to alias \"git\" to \"perf record git\"\n>>>> for a day or something.\n>>>\n>>> Yeah I should have mentioned that I'm mainly linking to the test suite\n>>> rendering as a demo.\n>>>\n>>> My actual use-case for this is to see what production nodes are spending\n>>> their time on, similar to what Microsoft is doing with their use of this\n>>> facility.\n>>>\n>>> The test suite serves as a really good test-case for the output, and to\n>>> stress-test my aggregation script, since we're pretty much guaranteed to\n>>> run all our commands, and cover a lot of unusual cases.\n>>>\n>>> It also shows that we've got a long way to go in improving the trace2\n>>> facility, i.e. adding region enter/leave for some of the things we spend\n>>> the most time on.\n>>>\n>>\n>> Very nice!\n>>\n>> Yes, there is more work to do to add more regions to get more\n>> granular data for interesting/problematic things.  My primary\n>> goal in this phase has been to get the basic machinery in place\n>> and be vetted with some universally interesting regions, such as\n>> reading/writing the index and the phases of status.\n>>\n>> Going forward, we can trivially (permanently) add new regions as we\n>> want.  I tend to use temporary \"experimental\" regions during my perf\n>> investigations so that I don't clutter up the mainline source with\n>> uninteresting noise.\n> \n> Indeed, a lot more regions are needed.\n> \n>> WRT the TODO's in your script:\n>>\n>> [] I don't think data events will be useful for your usage.  The data\n>> values are orthogonal to the time values.\n> \n> I haven't done this, so I'm not asserting that it's useful, but from\n> some brief grepping a few datapoints are overwhelmingly common, and can\n> be faked up into regions of sorts for the purposes of a flamegraph.\n> \n> E.g. \"git checkout\" will reliably have read/version early on, and then\n> write/version, in that case mostly/entirely redundant to the\n> do_{read,write}_index region, but in general I think we'll be able to\n> loosely plot data points say as \"given the median runtime, here's the\n> median % of time into the command we first encounter this data point\".\n\nInteresting.  I was thinking of just the data value itself, rather than\nthe time when it was emitted.\n\n> \n>> [] I would add the child_start/_exit events to the stack.  This will\n>> give you the names of non-builtin/shell commands and hooks.  The\n>> various \"child_class\" and \"use_shell\" and \"hook_name\" fields will help\n>> you avoid duplicate stack frames (which you'll get for builtin\n>> commands).\n> \n> Yeah that's very useful. Any reason not to do something like this:\n> \n>      diff --git a/git.c b/git.c\n>      index 1bf9c94550..6c926ae013 100644\n>      --- a/git.c\n>      +++ b/git.c\n>      @@ -698 +698 @@ static void execv_dashed_external(const char **argv)\n>      -       trace2_cmd_name(\"_run_dashed_\");\n>      +       trace2_cmd_name(is_builtin(argv[0]) ? argv[0] : \"_run_dashed_\");\n> \n> I haven't tested, but we e.g. report 'git-submodule' as just\n> '_run_dashed_', seems we could do better...\n> \n\nThe whole dispatch logic is a bit of a confusing mess between implicit\ndashed commands, the various types of alias expansion, fallback, and\netc, so I'm a little cautious here.  What I'm reporting here is that\nthe current process is not directly doing anything -- just spawning\n(or trying to spawn) a dashed command.  If that dashed command is bogus,\nwe may fallback and try an alias expansion (which is also spawned even\nif it is a builtin command).\n\nFor dashed commands that resolve to builtin commands, we will get trace2\ndata from the child process itself, so we can ignore the data for the\n_run_dashed_ process completely (when we are OK with ignoring process\nspawning overhead).\n\nFor dashed commands that are shell scripts, we won't get any trace2 data\nfor the script itself, but we will get events for any git commands that\nthe script runs.  These are somewhat confusingly attributed to the\n_run_dashed_ process.  It might be more useful to emit something like:\n      \"%s:%s, \"_run_dashed_\", cmd.args.argv[0]\nbut I'm not sure I want to suggest that yet.\n\nYou might try something like this:\n\n$ git config --local --add alias.xxx \"log --oneline\"\n$ export GIT_TR2_PERF=1\n$ ./git --exec-path=. xxx\n$ ./git --exec-path=. submodule status\n\nand see how the different processes are started.\n\nJeff\n\n"}]}