search for: massif

...oing. > 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 o...

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

...044196b412f. That helped a bit, but not yet fully. Looks like it might be still reachable memory, so leakcheck isn't that helpful. Oooh. I think I see. For various reasons the symbol names we generate are unique over time. But the interned strings aren't cleared ever. Is that right? With massif, I see: -------------------------------------------------------------------------------- n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) -------------------------------------------------------------------------------- 22 62,022,701,974 2,766,072 2,664...

...g like that? That is wrong? here is my printer share definition on smb.conf: [printers] comment = All Printers path = /var/spool/samba browseable = no guest ok = yes printable = yes print command = lpr -r -Znoff -P%p %s And the definition in /etc/printcap: dfax_ps|Envoi massif postscript:\ :lp=/dev/null:\ :sd=/u/spool/lpd/dfax_ps:\ :sh:\ :mx#0:\ :if=/util/Filters/nocover_ps: Thanks a lot, Sam -- Samuel Jobin sjobin@gniinc.net Software Development _____________________ --== GNI inc.==-- 5075 Wilfrid-Hamel O. Suite 220 Qu?bec (QC), G2E 5G3 Phone: (418) 86...

As to tremor fixed-point implementation, i got several questions, and hopefully some one can help me out. Thanks a lot! 1. For DSP chips with small and limited memory, how much memory do we really need for saving all codebooks before we start to decode audio packets? Can the bit-rate give us some clues? Is there some simple guidelines for this? 2. For CRC error protection, it seems to me that

...e it might be still >> reachable memory, so leakcheck isn't that helpful. >> >> Oooh. I think I see. For various reasons the symbol names we generate >> are unique over time. But the interned strings aren't cleared ever. Is >> that right? >> >> With massif, I see: >> >> >> -------------------------------------------------------------------------------- >> n time(i) total(B) useful-heap(B) extra-heap(B) >> stacks(B) >> >> ----------------------------------------------------------------------...

> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Just in case it

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *

On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Just in case it interests anyone else, I'm playing around with trying to > broaden the MCStreamer API to allow for emission of bytes without copying > the contents into a local buffer first (either because