Oops, I thought I had done this last time, but maybe not. Submit the

name change.


git-svn-id: http://gperftools.googlecode.com/svn/trunk@96 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
This commit is contained in:
csilvers 2010-06-23 16:42:31 +00:00
parent cb7393cbe2
commit 488eee994d

View File

@ -1,99 +1,104 @@
--- COMPILING --- COMPILING
This project has begun being ported to Windows. A working solution This project has begun being ported to Windows. A working solution
file exists in this directory: file exists in this directory:
google-perftools.sln google-perftools.sln
You can load this solution file into either VC++ 7.1 (Visual Studio You can load this solution file into either VC++ 7.1 (Visual Studio
2003) or VC++ 8.0 (Visual Studio 2005) -- in the latter case, it will 2003) or VC++ 8.0 (Visual Studio 2005) -- in the latter case, it will
automatically convert the files to the latest format for you. automatically convert the files to the latest format for you.
When you build the solution, it will create a number of unittests, When you build the solution, it will create a number of unittests,
which you can run by hand (or, more easily, under the Visual Studio which you can run by hand (or, more easily, under the Visual Studio
debugger) to make sure everything is working properly on your system. debugger) to make sure everything is working properly on your system.
The binaries will end up in a directory called "debug" or "release" in The binaries will end up in a directory called "debug" or "release" in
the top-level directory (next to the .sln file). It will also create the top-level directory (next to the .sln file). It will also create
two binaries, nm-pdb and addr2line-pdb, which you should install in two binaries, nm-pdb and addr2line-pdb, which you should install in
the same directory you install the 'pprof' perl script. the same directory you install the 'pprof' perl script.
Note that these systems are set to build in Debug mode by default. I don't know very much about how to install DLLs on Windows, so you'll
You may want to change them to Release mode. have to figure out that part for yourself. If you choose to just
re-use the existing .sln, make sure you set the IncludeDir's
To use tcmalloc_minimal in your own projects, you should only need to appropriately! Look at the properties for libtcmalloc_minimal.dll.
build the dll and install it someplace, so you can link it into
further binaries. To use the dll, you need to add the following to Note that these systems are set to build in Debug mode by default.
the linker line of your executable: You may want to change them to Release mode.
"libtcmalloc_minimal.lib" /INCLUDE:"__tcmalloc"
To use tcmalloc_minimal in your own projects, you should only need to
Here is how to accomplish this in Visual Studio 2005 (VC8): build the dll and install it someplace, so you can link it into
further binaries. To use the dll, you need to add the following to
1) Have your executable depend on the tcmalloc library by selecting the linker line of your executable:
"Project Dependencies..." from the "Project" menu. Your executable "libtcmalloc_minimal.lib" /INCLUDE:"__tcmalloc"
should depend on "libtcmalloc_minimal".
Here is how to accomplish this in Visual Studio 2005 (VC8):
2) Have your executable depend on a tcmalloc symbol -- this is
necessary so the linker doesn't "optimize out" the libtcmalloc 1) Have your executable depend on the tcmalloc library by selecting
dependency -- by right-clicking on your executable's project (in "Project Dependencies..." from the "Project" menu. Your executable
the solution explorer), selecting Properties from the pull-down should depend on "libtcmalloc_minimal".
menu, then selecting "Configuration Properties" -> "Linker" ->
"Input". Then, in the "Force Symbol References" field, enter the 2) Have your executable depend on a tcmalloc symbol -- this is
text "__tcmalloc" (without the quotes). Be sure to do this for both necessary so the linker doesn't "optimize out" the libtcmalloc
debug and release modes! dependency -- by right-clicking on your executable's project (in
the solution explorer), selecting Properties from the pull-down
You can also link tcmalloc code in statically -- see the example menu, then selecting "Configuration Properties" -> "Linker" ->
project tcmalloc_minimal_unittest-static, which does this. For this "Input". Then, in the "Force Symbol References" field, enter the
to work, you'll need to add "/D PERFTOOLS_DLL_DECL=" to the compile text "__tcmalloc" (without the quotes). Be sure to do this for both
line of every perftools .cc file. You do not need to depend on the debug and release modes!
tcmalloc symbol in this case (that is, you don't need to do either
step 1 or step 2 from above). You can also link tcmalloc code in statically -- see the example
project tcmalloc_minimal_unittest-static, which does this. For this
An alternative to all the above is to statically link your application to work, you'll need to add "/D PERFTOOLS_DLL_DECL=" to the compile
with libc, and then replace its malloc with tcmalloc. This allows you line of every perftools .cc file. You do not need to depend on the
to just build and link your program normally; the tcmalloc support tcmalloc symbol in this case (that is, you don't need to do either
comes in a post-processing step. This is more reliable than the above step 1 or step 2 from above).
technique (which depends on run-time patching, which is inherently
fragile), though more work to set up. For details, see An alternative to all the above is to statically link your application
https://groups.google.com/group/google-perftools/browse_thread/thread/41cd3710af85e57b with libc, and then replace its malloc with tcmalloc. This allows you
to just build and link your program normally; the tcmalloc support
comes in a post-processing step. This is more reliable than the above
--- THE HEAP-PROFILER technique (which depends on run-time patching, which is inherently
fragile), though more work to set up. For details, see
The heap-profiler has had a preliminary port to Windows. It has not https://groups.google.com/group/google-perftools/browse_thread/thread/41cd3710af85e57b
been well tested, and probably does not work at all when Frame Pointer
Optimization (FPO) is enabled -- that is, in release mode. The other
features of perftools, such as the cpu-profiler and leak-checker, have --- THE HEAP-PROFILER
not yet been ported to Windows at all.
The heap-profiler has had a preliminary port to Windows. It has not
been well tested, and probably does not work at all when Frame Pointer
--- ISSUES Optimization (FPO) is enabled -- that is, in release mode. The other
features of perftools, such as the cpu-profiler and leak-checker, have
NOTE FOR WIN2K USERS: According to reports not yet been ported to Windows at all.
(http://code.google.com/p/google-perftools/issues/detail?id=127)
the stack-tracing necessary for the heap-profiler does not work on
Win2K. The best workaround is, if you are building on a Win2k system --- ISSUES
is to add "/D NO_TCMALLOC_SAMPLES=" to your build, to turn off the
stack-tracing. You will not be able to use the heap-profiler if you NOTE FOR WIN2K USERS: According to reports
do this. (http://code.google.com/p/google-perftools/issues/detail?id=127)
the stack-tracing necessary for the heap-profiler does not work on
NOTE ON _MSIZE and _RECALLOC: The tcmalloc version of _msize returns Win2K. The best workaround is, if you are building on a Win2k system
the size of the region tcmalloc allocated for you -- which is at least is to add "/D NO_TCMALLOC_SAMPLES=" to your build, to turn off the
as many bytes you asked for, but may be more. (btw, these *are* bytes stack-tracing. You will not be able to use the heap-profiler if you
you own, even if you didn't ask for all of them, so it's correct code do this.
to access all of them if you want.) Unfortunately, the Windows CRT
_recalloc() routine assumes that _msize returns exactly as many bytes NOTE ON _MSIZE and _RECALLOC: The tcmalloc version of _msize returns
as were requested. As a result, _recalloc() may not zero out new the size of the region tcmalloc allocated for you -- which is at least
bytes correctly. IT'S SAFEST NOT TO USE _RECALLOC WITH TCMALLOC. as many bytes you asked for, but may be more. (btw, these *are* bytes
_recalloc() is a tricky routine to use in any case (it's not safe to you own, even if you didn't ask for all of them, so it's correct code
use with realloc, for instance). to access all of them if you want.) Unfortunately, the Windows CRT
_recalloc() routine assumes that _msize returns exactly as many bytes
as were requested. As a result, _recalloc() may not zero out new
I have little experience with Windows programming, so there may be bytes correctly. IT'S SAFEST NOT TO USE _RECALLOC WITH TCMALLOC.
better ways to set this up than I've done! If you run across any _recalloc() is a tricky routine to use in any case (it's not safe to
problems, please post to the google-perftools Google Group, or report use with realloc, for instance).
them on the google-perftools Google Code site:
http://groups.google.com/group/google-perftools
http://code.google.com/p/google-perftools/issues/list I have little experience with Windows programming, so there may be
better ways to set this up than I've done! If you run across any
-- craig problems, please post to the google-perftools Google Group, or report
them on the google-perftools Google Code site:
Last modified: 3 February 2010 http://groups.google.com/group/google-perftools
http://code.google.com/p/google-perftools/issues/list
-- craig
Last modified: 3 February 2010