{"id":15345692,"url":"https://github.com/git-hulk/gperftools","last_synced_at":"2026-01-06T17:17:16.645Z","repository":{"id":31641726,"uuid":"35206962","full_name":"git-hulk/gperftools","owner":"git-hulk","description":"Automatically exported from code.google.com/p/gperftools","archived":false,"fork":false,"pushed_at":"2015-05-07T08:06:25.000Z","size":2916,"stargazers_count":0,"open_issues_count":4,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-02-01T21:42:36.431Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"freeCodeCamp/freeCodeCamp","license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/git-hulk.png","metadata":{"files":{"readme":"README","changelog":"ChangeLog","contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-05-07T08:03:53.000Z","updated_at":"2015-05-07T08:04:46.000Z","dependencies_parsed_at":"2022-08-25T22:11:00.502Z","dependency_job_id":null,"html_url":"https://github.com/git-hulk/gperftools","commit_stats":null,"previous_names":[],"tags_count":46,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/git-hulk%2Fgperftools","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/git-hulk%2Fgperftools/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/git-hulk%2Fgperftools/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/git-hulk%2Fgperftools/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/git-hulk","download_url":"https://codeload.github.com/git-hulk/gperftools/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245905124,"owners_count":20691733,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-01T11:14:53.281Z","updated_at":"2026-01-06T17:17:16.602Z","avatar_url":"https://github.com/git-hulk.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"IMPORTANT NOTE FOR 64-BIT USERS\n-------------------------------\nThere are known issues with some perftools functionality on x86_64\nsystems.  See 64-BIT ISSUES, below.\n\n\nTCMALLOC\n--------\nJust link in -ltcmalloc or -ltcmalloc_minimal to get the advantages of\ntcmalloc -- a replacement for malloc and new.  See below for some\nenvironment variables you can use with tcmalloc, as well.\n\ntcmalloc functionality is available on all systems we've tested; see\nINSTALL for more details.  See README_windows.txt for instructions on\nusing tcmalloc on Windows.\n\nNOTE: When compiling with programs with gcc, that you plan to link\nwith libtcmalloc, it's safest to pass in the flags\n\n -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free\n\nwhen compiling.  gcc makes some optimizations assuming it is using its\nown, built-in malloc; that assumption obviously isn't true with\ntcmalloc.  In practice, we haven't seen any problems with this, but\nthe expected risk is highest for users who register their own malloc\nhooks with tcmalloc (using gperftools/malloc_hook.h).  The risk is\nlowest for folks who use tcmalloc_minimal (or, of course, who pass in\nthe above flags :-) ).\n\n\nHEAP PROFILER\n-------------\nSee doc/heap-profiler.html for information about how to use tcmalloc's\nheap profiler and analyze its output.\n\nAs a quick-start, do the following after installing this package:\n\n1) Link your executable with -ltcmalloc\n2) Run your executable with the HEAPPROFILE environment var set:\n     $ HEAPPROFILE=/tmp/heapprof \u003cpath/to/binary\u003e [binary args]\n3) Run pprof to analyze the heap usage\n     $ pprof \u003cpath/to/binary\u003e /tmp/heapprof.0045.heap  # run 'ls' to see options\n     $ pprof --gv \u003cpath/to/binary\u003e /tmp/heapprof.0045.heap\n\nYou can also use LD_PRELOAD to heap-profile an executable that you\ndidn't compile.\n\nThere are other environment variables, besides HEAPPROFILE, you can\nset to adjust the heap-profiler behavior; c.f. \"ENVIRONMENT VARIABLES\"\nbelow.\n\nThe heap profiler is available on all unix-based systems we've tested;\nsee INSTALL for more details.  It is not currently available on Windows.\n\n\nHEAP CHECKER\n------------\nSee doc/heap-checker.html for information about how to use tcmalloc's\nheap checker.\n\nIn order to catch all heap leaks, tcmalloc must be linked *last* into\nyour executable.  The heap checker may mischaracterize some memory\naccesses in libraries listed after it on the link line.  For instance,\nit may report these libraries as leaking memory when they're not.\n(See the source code for more details.)\n\nHere's a quick-start for how to use:\n\nAs a quick-start, do the following after installing this package:\n\n1) Link your executable with -ltcmalloc\n2) Run your executable with the HEAPCHECK environment var set:\n     $ HEAPCHECK=1 \u003cpath/to/binary\u003e [binary args]\n\nOther values for HEAPCHECK: normal (equivalent to \"1\"), strict, draconian\n\nYou can also use LD_PRELOAD to heap-check an executable that you\ndidn't compile.\n\nThe heap checker is only available on Linux at this time; see INSTALL\nfor more details.\n\n\nCPU PROFILER\n------------\nSee doc/cpu-profiler.html for information about how to use the CPU\nprofiler and analyze its output.\n\nAs a quick-start, do the following after installing this package:\n\n1) Link your executable with -lprofiler\n2) Run your executable with the CPUPROFILE environment var set:\n     $ CPUPROFILE=/tmp/prof.out \u003cpath/to/binary\u003e [binary args]\n3) Run pprof to analyze the CPU usage\n     $ pprof \u003cpath/to/binary\u003e /tmp/prof.out      # -pg-like text output\n     $ pprof --gv \u003cpath/to/binary\u003e /tmp/prof.out # really cool graphical output\n\nThere are other environment variables, besides CPUPROFILE, you can set\nto adjust the cpu-profiler behavior; cf \"ENVIRONMENT VARIABLES\" below.\n\nThe CPU profiler is available on all unix-based systems we've tested;\nsee INSTALL for more details.  It is not currently available on Windows.\n\nNOTE: CPU profiling doesn't work after fork (unless you immediately\n      do an exec()-like call afterwards).  Furthermore, if you do\n      fork, and the child calls exit(), it may corrupt the profile\n      data.  You can use _exit() to work around this.  We hope to have\n      a fix for both problems in the next release of perftools\n      (hopefully perftools 1.2).\n\n\nEVERYTHING IN ONE\n-----------------\nIf you want the CPU profiler, heap profiler, and heap leak-checker to\nall be available for your application, you can do:\n   gcc -o myapp ... -lprofiler -ltcmalloc\n\nHowever, if you have a reason to use the static versions of the\nlibrary, this two-library linking won't work:\n   gcc -o myapp ... /usr/lib/libprofiler.a /usr/lib/libtcmalloc.a  # errors!\n\nInstead, use the special libtcmalloc_and_profiler library, which we\nmake for just this purpose:\n   gcc -o myapp ... /usr/lib/libtcmalloc_and_profiler.a\n\n\nCONFIGURATION OPTIONS\n---------------------\nFor advanced users, there are several flags you can pass to\n'./configure' that tweak tcmalloc performace.  (These are in addition\nto the environment variables you can set at runtime to affect\ntcmalloc, described below.)  See the INSTALL file for details.\n\n\nENVIRONMENT VARIABLES\n---------------------\nThe cpu profiler, heap checker, and heap profiler will lie dormant,\nusing no memory or CPU, until you turn them on.  (Thus, there's no\nharm in linking -lprofiler into every application, and also -ltcmalloc\nassuming you're ok using the non-libc malloc library.)\n\nThe easiest way to turn them on is by setting the appropriate\nenvironment variables.  We have several variables that let you\nenable/disable features as well as tweak parameters.\n\nHere are some of the most important variables:\n\nHEAPPROFILE=\u003cpre\u003e -- turns on heap profiling and dumps data using this prefix\nHEAPCHECK=\u003ctype\u003e  -- turns on heap checking with strictness 'type'\nCPUPROFILE=\u003cfile\u003e -- turns on cpu profiling and dumps data to this file.\nPROFILESELECTED=1 -- if set, cpu-profiler will only profile regions of code\n                     surrounded with ProfilerEnable()/ProfilerDisable().\nCPUPROFILE_FREQUENCY=x-- how many interrupts/second the cpu-profiler samples.\n\nTCMALLOC_DEBUG=\u003clevel\u003e -- the higher level, the more messages malloc emits\nMALLOCSTATS=\u003clevel\u003e    -- prints memory-use stats at program-exit\n\nFor a full list of variables, see the documentation pages:\n   doc/cpuprofile.html\n   doc/heapprofile.html\n   doc/heap_checker.html\n\n\nCOMPILING ON NON-LINUX SYSTEMS\n------------------------------\n\nPerftools was developed and tested on x86 Linux systems, and it works\nin its full generality only on those systems.  However, we've\nsuccessfully ported much of the tcmalloc library to FreeBSD, Solaris\nx86, and Darwin (Mac OS X) x86 and ppc; and we've ported the basic\nfunctionality in tcmalloc_minimal to Windows.  See INSTALL for details.\nSee README_windows.txt for details on the Windows port.\n\n\nPERFORMANCE\n-----------\n\nIf you're interested in some third-party comparisons of tcmalloc to\nother malloc libraries, here are a few web pages that have been\nbrought to our attention.  The first discusses the effect of using\nvarious malloc libraries on OpenLDAP.  The second compares tcmalloc to\nwin32's malloc.\n  http://www.highlandsun.com/hyc/malloc/\n  http://gaiacrtn.free.fr/articles/win32perftools.html\n\nIt's possible to build tcmalloc in a way that trades off faster\nperformance (particularly for deletes) at the cost of more memory\nfragmentation (that is, more unusable memory on your system).  See the\nINSTALL file for details.\n\n\nOLD SYSTEM ISSUES\n-----------------\n\nWhen compiling perftools on some old systems, like RedHat 8, you may\nget an error like this:\n    ___tls_get_addr: symbol not found\n\nThis means that you have a system where some parts are updated enough\nto support Thread Local Storage, but others are not.  The perftools\nconfigure script can't always detect this kind of case, leading to\nthat error.  To fix it, just comment out (or delete) the line\n   #define HAVE_TLS 1\nin your config.h file before building.\n\n\n64-BIT ISSUES\n-------------\n\nThere are two issues that can cause program hangs or crashes on x86_64\n64-bit systems, which use the libunwind library to get stack-traces.\nNeither issue should affect the core tcmalloc library; they both\naffect the perftools tools such as cpu-profiler, heap-checker, and\nheap-profiler.\n\n1) Some libc's -- at least glibc 2.4 on x86_64 -- have a bug where the\nlibc function dl_iterate_phdr() acquires its locks in the wrong\norder.  This bug should not affect tcmalloc, but may cause occasional\ndeadlock with the cpu-profiler, heap-profiler, and heap-checker.\nIts likeliness increases the more dlopen() commands an executable has.\nMost executables don't have any, though several library routines like\ngetgrgid() call dlopen() behind the scenes.\n\n2) On x86-64 64-bit systems, while tcmalloc itself works fine, the\ncpu-profiler tool is unreliable: it will sometimes work, but sometimes\ncause a segfault.  I'll explain the problem first, and then some\nworkarounds.\n\nNote that this only affects the cpu-profiler, which is a\ngperftools feature you must turn on manually by setting the\nCPUPROFILE environment variable.  If you do not turn on cpu-profiling,\nyou shouldn't see any crashes due to perftools.\n\nThe gory details: The underlying problem is in the backtrace()\nfunction, which is a built-in function in libc.\nBacktracing is fairly straightforward in the normal case, but can run\ninto problems when having to backtrace across a signal frame.\nUnfortunately, the cpu-profiler uses signals in order to register a\nprofiling event, so every backtrace that the profiler does crosses a\nsignal frame.\n\nIn our experience, the only time there is trouble is when the signal\nfires in the middle of pthread_mutex_lock.  pthread_mutex_lock is\ncalled quite a bit from system libraries, particularly at program\nstartup and when creating a new thread.\n\nThe solution: The dwarf debugging format has support for 'cfi\nannotations', which make it easy to recognize a signal frame.  Some OS\ndistributions, such as Fedora and gentoo 2007.0, already have added\ncfi annotations to their libc.  A future version of libunwind should\nrecognize these annotations; these systems should not see any\ncrashses.\n\nWorkarounds: If you see problems with crashes when running the\ncpu-profiler, consider inserting ProfilerStart()/ProfilerStop() into\nyour code, rather than setting CPUPROFILE.  This will profile only\nthose sections of the codebase.  Though we haven't done much testing,\nin theory this should reduce the chance of crashes by limiting the\nsignal generation to only a small part of the codebase.  Ideally, you\nwould not use ProfilerStart()/ProfilerStop() around code that spawns\nnew threads, or is otherwise likely to cause a call to\npthread_mutex_lock!\n\n---\n17 May 2011\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgit-hulk%2Fgperftools","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgit-hulk%2Fgperftools","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgit-hulk%2Fgperftools/lists"}