On 11/11/2011 11:39 AM, Chandler Carruth wrote:> On Fri, Nov 11, 2011 at 11:36 AM, reed kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > Is anybody using the google heap profiler to analyze clang/llvm ?? > > http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html > > If so, do you know how to modify the build scripts to enable that. > > Tia. > > > I have tried to use this in the past without terribly much success. > Instead, I usually use Valgrind to analyze the allocation patterns: > http://valgrind.org/docs/manual/ms-manual.htmlI've been using valgrind too. It seems to work fine. I need to independently validate some numbers though because the answer has big implications for some planning we are doing. Reed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111111/f513a737/attachment.html>
On Fri, Nov 11, 2011 at 11:45 AM, reed kotler <rkotler at mips.com> wrote:> ** > On 11/11/2011 11:39 AM, Chandler Carruth wrote: > > On Fri, Nov 11, 2011 at 11:36 AM, reed kotler <rkotler at mips.com> wrote: > >> Is anybody using the google heap profiler to analyze clang/llvm ?? >> >> http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html >> >> If so, do you know how to modify the build scripts to enable that. >> >> Tia. > > > I have tried to use this in the past without terribly much success. > Instead, I usually use Valgrind to analyze the allocation patterns: > http://valgrind.org/docs/manual/ms-manual.html > > I've been using valgrind too. It seems to work fine. > > I need to independently validate some numbers though because the answer > has big implications for some planning we are doing. >In the past I have use the Google perf tools by using LDPRELOAD to inject them into the running binary. Note that the subprocess-ing can impact things, you need to drop down to the cc1 invocation first. Still, I have found that the heap profiling in these tools is strictly inferior to massif. I'd trust it. There are lots of flags you can give to massif to cause it to be very very accurate despite being quite slow. Do those help? You can also look at the '-print-stats' option (or something like that) which prints out internal allocation stats for various significant parts of Clang, and might be able to correlate the two to gain confidence. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111111/ad216b8f/attachment.html>
dtrace can also be a useful tool for validating or investigating some of the numbers. - Daniel On Fri, Nov 11, 2011 at 11:49 AM, Chandler Carruth <chandlerc at google.com> wrote:> On Fri, Nov 11, 2011 at 11:45 AM, reed kotler <rkotler at mips.com> wrote: >> >> On 11/11/2011 11:39 AM, Chandler Carruth wrote: >> >> On Fri, Nov 11, 2011 at 11:36 AM, reed kotler <rkotler at mips.com> wrote: >>> >>> Is anybody using the google heap profiler to analyze clang/llvm ?? >>> >>> http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html >>> >>> If so, do you know how to modify the build scripts to enable that. >>> >>> Tia. >> >> I have tried to use this in the past without terribly much success. >> Instead, I usually use Valgrind to analyze the allocation patterns: >> http://valgrind.org/docs/manual/ms-manual.html >> >> I've been using valgrind too. It seems to work fine. >> >> I need to independently validate some numbers though because the answer >> has big implications for some planning we are doing. > > In the past I have use the Google perf tools by using LDPRELOAD to inject > them into the running binary. > Note that the subprocess-ing can impact things, you need to drop down to the > cc1 invocation first. > Still, I have found that the heap profiling in these tools is strictly > inferior to massif. I'd trust it. There are lots of flags you can give to > massif to cause it to be very very accurate despite being quite slow. Do > those help? > You can also look at the '-print-stats' option (or something like that) > which prints out internal allocation stats for various significant parts of > Clang, and might be able to correlate the two to gain confidence. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >