{"thread":{"id":"35843","subject":"Profiling support?","startedAt":"2014-02-11T11:17:40Z","lastAt":"2014-02-16T17:05:42Z","messageCount":10,"participants":["David Kastrup","Duy Nguyen","John Keeping","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"234610","messageId":"87d2itc2zv.fsf@fencepost.gnu.org","threadId":"35843","inReplyTo":null,"subject":"Profiling support?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-11T11:17:40Z","receivedAt":"2014-02-11T11:17:40Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nLooking in the Makefile, I just find support for coverage reports using\ngcov. Whatever is there with \"profile\" in it seems to be for\nprofile-based compilation rather than using gprof.\n\nNow since I've managed to push most of the runtime for basic git-blame\noperation out of blame.c proper, it becomes important to figure out\nwhere most of the remaining runtime (a sizable part of that being system\ntime) is being spent. Loop counts like that provided by gcov (or am I\nmissing something here?) are not helpful for that, I think I rather need\nthe kind of per-function breakdown that gprof provides.\n\nIs there a reason there are no prewired recipes or advice for using\ngprof on git? Is there a way to get the work done, namely seeing the\nactual distribution of call times (rather than iterations) using gcov so\nthat this is not necessary?\n\n-- \nDavid Kastrup\n"},{"id":"234611","messageId":"CACsJy8BAD3cm2BLSapJ2fhkGiYjDKqW1TQ1yu0XPwTyEfL2oLQ@mail.gmail.com","threadId":"35843","inReplyTo":"87d2itc2zv.fsf@fencepost.gnu.org","subject":"Re: Profiling support?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-11T13:18:52Z","receivedAt":"2014-02-11T13:18:52Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup wrote:\n>\n> Looking in the Makefile, I just find support for coverage reports using\n> gcov. Whatever is there with \"profile\" in it seems to be for\n> profile-based compilation rather than using gprof.\n>\n> Now since I've managed to push most of the runtime for basic git-blame\n> operation out of blame.c proper, it becomes important to figure out\n> where most of the remaining runtime (a sizable part of that being system\n> time) is being spent. Loop counts like that provided by gcov (or am I\n> missing something here?) are not helpful for that, I think I rather need\n> the kind of per-function breakdown that gprof provides.\n>\n> Is there a reason there are no prewired recipes or advice for using\n> gprof on git? Is there a way to get the work done, namely seeing the\n> actual distribution of call times (rather than iterations) using gcov so\n> that this is not necessary?\n\nWould perf help? No changes required, and almost no overhead, I think.\n-- \nDuy\n"},{"id":"234612","messageId":"878uthbtjg.fsf@fencepost.gnu.org","threadId":"35843","inReplyTo":"CACsJy8BAD3cm2BLSapJ2fhkGiYjDKqW1TQ1yu0XPwTyEfL2oLQ@mail.gmail.com","subject":"Re: Profiling support?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-11T14:41:55Z","receivedAt":"2014-02-11T14:41:55Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Duy Nguyen writes:\n\n> On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup wrote:\n>>\n>> Looking in the Makefile, I just find support for coverage reports using\n>> gcov. Whatever is there with \"profile\" in it seems to be for\n>> profile-based compilation rather than using gprof.\n>>\n>> Now since I've managed to push most of the runtime for basic git-blame\n>> operation out of blame.c proper, it becomes important to figure out\n>> where most of the remaining runtime (a sizable part of that being system\n>> time) is being spent. Loop counts like that provided by gcov (or am I\n>> missing something here?) are not helpful for that, I think I rather need\n>> the kind of per-function breakdown that gprof provides.\n>>\n>> Is there a reason there are no prewired recipes or advice for using\n>> gprof on git? Is there a way to get the work done, namely seeing the\n>> actual distribution of call times (rather than iterations) using gcov so\n>> that this is not necessary?\n>\n> Would perf help? No changes required, and almost no overhead, I think.\n\nNot useful. It would be probably nice for nailing down the performance\ngains when the work is finished so that future regressions will be\nnoticeable. It's reasonable easy to create a test case that will take\nhours with the current git-blame and would finish in seconds with the\nimproved one.\n\nBut it's not useful at all for figuring out the hotspots within the\ngit-blame binary.\n\nI made do with something like\n\nmake CFLAGS=-pg LDFLAGS=-pg\n\nbut it is sort of annoying that the required \"make clean\" apparently\nalso cleans out the coverage files: for sensible finding of bad stuff\none needs them as well.\n\nAt any rate, I'll probably figure out something eventually. No idea\nwhether I'll get around to writing some useful instructions. At the\ncurrent point of time, it would appear that a large part of the\nremaining user time (about half) is spent in xdl_hash_record so x86_64\narchitectures already benefit from XDL_FAST_HASH (which seems to hurt\nmore than it would help with my i686). So finding a good fast hash\nfunction would likely help. The current hash function _and_ the\nXDL_FAST_HASH replacement used on x86_64 are a drag here because they\nare not easily split into a word-unaligned, a (typically long and thus\nmost performance-relevant) word-aligned, and another word-unaligned part\nin a manner that allows calculating the same hash for different\nalignments. Something like a CRC lends itself much better to that, but\nsince its basic operation is more complex on a general-purpose CPU, it's\nnot likely to result in a net win.\n\nIn assembly language, add-and-multiply operations modulo 2^32-1 are\npretty easy to do and lend themselves well to considering alignment at\nthe end, but in C, access to mixed precision multiplications and the\ncarry flag are rather awkward.\n\n-- \nDavid Kastrup\n"},{"id":"234615","messageId":"20140211151451.GA15032@serenity.lan","threadId":"35843","inReplyTo":"878uthbtjg.fsf@fencepost.gnu.org","subject":"Re: Profiling support?","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-02-11T15:14:52Z","receivedAt":"2014-02-11T15:14:52Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:\n> Duy Nguyen writes:\n> \n> > On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup wrote:\n> >>\n> >> Looking in the Makefile, I just find support for coverage reports using\n> >> gcov. Whatever is there with \"profile\" in it seems to be for\n> >> profile-based compilation rather than using gprof.\n> >>\n> >> Now since I've managed to push most of the runtime for basic git-blame\n> >> operation out of blame.c proper, it becomes important to figure out\n> >> where most of the remaining runtime (a sizable part of that being system\n> >> time) is being spent. Loop counts like that provided by gcov (or am I\n> >> missing something here?) are not helpful for that, I think I rather need\n> >> the kind of per-function breakdown that gprof provides.\n> >>\n> >> Is there a reason there are no prewired recipes or advice for using\n> >> gprof on git? Is there a way to get the work done, namely seeing the\n> >> actual distribution of call times (rather than iterations) using gcov so\n> >> that this is not necessary?\n> >\n> > Would perf help? No changes required, and almost no overhead, I think.\n> \n> Not useful. It would be probably nice for nailing down the performance\n> gains when the work is finished so that future regressions will be\n> noticeable. It's reasonable easy to create a test case that will take\n> hours with the current git-blame and would finish in seconds with the\n> improved one.\n> \n> But it's not useful at all for figuring out the hotspots within the\n> git-blame binary.\n\nI would have thought the annotation described at [1] is exactly what\nyou're looking for, isn't it?\n\nAlternatively, I've had some success with callgrind and kCachegrind in\nthe past.\n\n[1] https://perf.wiki.kernel.org/index.php/Tutorial#Source_level_analysis_with_perf_annotate\n"},{"id":"234616","messageId":"874n45brs4.fsf@fencepost.gnu.org","threadId":"35843","inReplyTo":"20140211151451.GA15032@serenity.lan","subject":"Re: Profiling support?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-11T15:19:55Z","receivedAt":"2014-02-11T15:19:55Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"John Keeping writes:\n\n> On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:\n>> Duy Nguyen writes:\n>>\n>> > Would perf help? No changes required, and almost no overhead, I think.\n>> \n>> Not useful. It would be probably nice for nailing down the performance\n>> gains when the work is finished so that future regressions will be\n>> noticeable. It's reasonable easy to create a test case that will take\n>> hours with the current git-blame and would finish in seconds with the\n>> improved one.\n>> \n>> But it's not useful at all for figuring out the hotspots within the\n>> git-blame binary.\n>\n> I would have thought the annotation described at [1] is exactly what\n> you're looking for, isn't it?\n>\n> Alternatively, I've had some success with callgrind and kCachegrind in\n> the past.\n>\n> [1]\n> https://perf.wiki.kernel.org/index.php/Tutorial#Source_level_analysis_with_perf_annotate\n\nMisunderstanding on my part. I thought this was about the \"make perf\"\nMakefile target. I'll have to take a look at what the perf utility\ndoes.\n\nThanks for the clarification.\n\n-- \nDavid Kastrup\n"},{"id":"234629","messageId":"87zjlx9xro.fsf@fencepost.gnu.org","threadId":"35843","inReplyTo":"874n45brs4.fsf@fencepost.gnu.org","subject":"Re: Profiling support?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-11T20:53:31Z","receivedAt":"2014-02-11T20:53:31Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Kastrup writes:\n\n> John Keeping writes:\n>\n>> On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:\n>>> Duy Nguyen writes:\n>>>\n>>> > Would perf help? No changes required, and almost no overhead, I think.\n>>> \n>>> Not useful. It would be probably nice for nailing down the performance\n>>> gains when the work is finished so that future regressions will be\n>>> noticeable. It's reasonable easy to create a test case that will take\n>>> hours with the current git-blame and would finish in seconds with the\n>>> improved one.\n>>> \n>>> But it's not useful at all for figuring out the hotspots within the\n>>> git-blame binary.\n>>\n>> I would have thought the annotation described at [1] is exactly what\n>> you're looking for, isn't it?\n>>\n>> Alternatively, I've had some success with callgrind and kCachegrind in\n>> the past.\n>>\n>> [1]\n>> https://perf.wiki.kernel.org/index.php/Tutorial#Source_level_analysis_with_perf_annotate\n>\n> Misunderstanding on my part. I thought this was about the \"make perf\"\n> Makefile target. I'll have to take a look at what the perf utility\n> does.\n>\n> Thanks for the clarification.\n\nLooks indeed like it could be useful. In the currently working code\nfrom me (last of the complex patch series), significant time is spent in\nmoving and allocating memory. It might make sense not to continue\nignoring the patch I proposed to get rid of the absurd realloc series in\nbuiltin/blame.c. While it may not be responsible for all of avoidable\nallocation churn, it's still large and untypical enough to mask further\nculprits.\n\n-- \nDavid Kastrup\n"},{"id":"234890","messageId":"87wqgv2hag.fsf@thomasrast.ch","threadId":"35843","inReplyTo":"87d2itc2zv.fsf@fencepost.gnu.org","subject":"Re: Profiling support?","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-16T15:44:55Z","receivedAt":"2014-02-16T15:44:55Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"David Kastrup writes:\n\n> Looking in the Makefile, I just find support for coverage reports using\n> gcov. Whatever is there with \"profile\" in it seems to be for\n> profile-based compilation rather than using gprof.\n[...]\n> Is there a reason there are no prewired recipes or advice for using\n> gprof on git? Is there a way to get the work done, namely seeing the\n> actual distribution of call times (rather than iterations) using gcov so\n> that this is not necessary?\n\nNo reason I'm aware of, other than that nobody ever wrote it.\n\nNote that I wouldn't exactly be surprised if the gcov targets had\nbitrotted without anyone noticing. I haven't heard of any heavy users.\nI originally wrote them to do some basic test coverage analysis, but\nthat's about it.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"234891","messageId":"871tz3xd3d.fsf@fencepost.gnu.org","threadId":"35843","inReplyTo":"87wqgv2hag.fsf@thomasrast.ch","subject":"Re: Profiling support?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-16T15:59:50Z","receivedAt":"2014-02-16T15:59:50Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Thomas Rast writes:\n\n> David Kastrup writes:\n>\n>> Looking in the Makefile, I just find support for coverage reports using\n>> gcov. Whatever is there with \"profile\" in it seems to be for\n>> profile-based compilation rather than using gprof.\n> [...]\n>> Is there a reason there are no prewired recipes or advice for using\n>> gprof on git? Is there a way to get the work done, namely seeing the\n>> actual distribution of call times (rather than iterations) using gcov so\n>> that this is not necessary?\n>\n> No reason I'm aware of, other than that nobody ever wrote it.\n\nA solid testing/benchmarking framework would quite seem like a useful\nGSoC project as it would make it easy for casual programmers to dip\ntheir feet into their personal bottlenecks, and it would make it much\neasier to find worthwhile hotspots for future projects taking the\nchallenge of speeding up core and/or specific operations.\n\n> Note that I wouldn't exactly be surprised if the gcov targets had\n> bitrotted without anyone noticing. I haven't heard of any heavy users.\n> I originally wrote them to do some basic test coverage analysis, but\n> that's about it.\n\nI've managed to make use of the outer sandwich layers: the prepare and\nthe evaluate stuff. I ran my own tests for benchmarking though.\n\nIt's enfuriatingly hard to get the stuff in the right directories and\nwith the right options, so that was already more helpful than it\nprobably should have been.\n\n-- \nDavid Kastrup\n"},{"id":"234902","messageId":"87mwhr2e1w.fsf@thomasrast.ch","threadId":"35843","inReplyTo":"871tz3xd3d.fsf@fencepost.gnu.org","subject":"Re: Profiling support?","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-16T16:54:51Z","receivedAt":"2014-02-16T16:54:51Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"David Kastrup writes:\n\n> Thomas Rast writes:\n>\n>> David Kastrup writes:\n>>\n>>> Looking in the Makefile, I just find support for coverage reports using\n>>> gcov. Whatever is there with \"profile\" in it seems to be for\n>>> profile-based compilation rather than using gprof.\n>> [...]\n>>> Is there a reason there are no prewired recipes or advice for using\n>>> gprof on git? Is there a way to get the work done, namely seeing the\n>>> actual distribution of call times (rather than iterations) using gcov so\n>>> that this is not necessary?\n>>\n>> No reason I'm aware of, other than that nobody ever wrote it.\n>\n> A solid testing/benchmarking framework would quite seem like a useful\n> GSoC project as it would make it easy for casual programmers to dip\n> their feet into their personal bottlenecks, and it would make it much\n> easier to find worthwhile hotspots for future projects taking the\n> challenge of speeding up core and/or specific operations.\n>\n>> Note that I wouldn't exactly be surprised if the gcov targets had\n>> bitrotted without anyone noticing. I haven't heard of any heavy users.\n>> I originally wrote them to do some basic test coverage analysis, but\n>> that's about it.\n>\n> I've managed to make use of the outer sandwich layers: the prepare and\n> the evaluate stuff. I ran my own tests for benchmarking though.\n\nUmm, are we even discussing the same thing here?\n\nAre you saying you ran profiling-instrumented code under the t/perf/\nsupport code? Sounds nice...\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"234903","messageId":"87lhxbvvh5.fsf@fencepost.gnu.org","threadId":"35843","inReplyTo":"87mwhr2e1w.fsf@thomasrast.ch","subject":"Re: Profiling support?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-16T17:05:42Z","receivedAt":"2014-02-16T17:05:42Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Thomas Rast writes:\n\n> David Kastrup writes:\n>\n>> Thomas Rast writes:\n>>\n>>> David Kastrup writes:\n>>>\n>>>> Looking in the Makefile, I just find support for coverage reports using\n>>>> gcov. Whatever is there with \"profile\" in it seems to be for\n>>>> profile-based compilation rather than using gprof.\n>>> [...]\n>>>> Is there a reason there are no prewired recipes or advice for using\n>>>> gprof on git? Is there a way to get the work done, namely seeing the\n>>>> actual distribution of call times (rather than iterations) using gcov so\n>>>> that this is not necessary?\n>>>\n>>> No reason I'm aware of, other than that nobody ever wrote it.\n>>\n>> A solid testing/benchmarking framework would quite seem like a useful\n>> GSoC project as it would make it easy for casual programmers to dip\n>> their feet into their personal bottlenecks, and it would make it much\n>> easier to find worthwhile hotspots for future projects taking the\n>> challenge of speeding up core and/or specific operations.\n>>\n>>> Note that I wouldn't exactly be surprised if the gcov targets had\n>>> bitrotted without anyone noticing. I haven't heard of any heavy users.\n>>> I originally wrote them to do some basic test coverage analysis, but\n>>> that's about it.\n>>\n>> I've managed to make use of the outer sandwich layers: the prepare and\n>> the evaluate stuff. I ran my own tests for benchmarking though.\n>\n> Umm, are we even discussing the same thing here?\n\nMaybe not.\n\n> Are you saying you ran profiling-instrumented code under the t/perf/\n> support code?\n\nNo. I used the toplevel Makefile targets coverage-clean,\ncoverage-compile and, after running my own problematic test cases,\ncoverage-report. I did not use the coverage-test target, nor did I\nventure into t/perf/ in any other way.\n\n-- \nDavid Kastrup\n"}]}