How to use static library artifacts in another build system about tcmalloc HOT 5 OPEN

gperftools was released by Google as Google Performance Tools many years ago. It diverged from Google's internal version--at the time, it was hard to keep things in-sync as described by Titus Winters in his 2017 CppCon talk and the "Software Engineering at Google Book"--and ended up being adopted by the community. There's further background here.

This version follows the one used in Google production and has a number of new features and optimizations.

from tcmalloc.

Why didn't I Google that? :D Long day after work maybe. Thank you so much for the help and fast response here. We might want to revisit trying to get this version of tcmalloc into our projects again, perhaps by spending time to contribute an Abesil-like CMake build as discussed in #4. As far as I'm concerned, this can be closed from my end. I think I have everything I need for now.

from tcmalloc.

Side point: If you're using Bazel for the TCMalloc build, https://github.com/bazelbuild/buildtools/tree/master/buildozer can help with manipulations of the BUILD files. That said, I think your sed commands are accomplishing their goal correctly.

I think the issue is that TCMalloc is comprised of multiple libraries which ordinarily all get pulled in by statically linking the main TCMalloc target. Most of this is an implementation detail, for ease of testing (common.a, several .a's under internal, etc.), but these also have dependencies on Abseil. Linking in these libraries would likely resolve the undefined reference problem.

The broader issue, though, is with a fully static tcmalloc.a inclusive of the Abseil dependencies, since any binary that links both that flavor of TCMalloc would get ODR clashes if it also depended on Abseil.

from tcmalloc.

Ah, I see. Thank you for the explanation. There are pros and cons of depending on third party libraries, I guess. I was hoping to use this version in some projects I'm working on, but I can continue to use the latest version from gperftools since my projects use autotools for building.

How is this tcmalloc different from the one that's included in gperftools? Is the one in gperftools planned to be EOL'd? Does this tcmalloc have API changes or maybe more recent cleanup/performance work that the one in gperftools doesn't have?

from tcmalloc.

Hi, @ckennelly

Can you comment on the performance impact on single-threaded benchmarks (such as SPEC2006, SPEC2017) of these two tcmalloc versions (i.e. tcmalloc in gperftools and the newer git-tcmalloc)? There are a couple of SPEC benchmarks that benefit noticeably from tcmalloc. Does the newer tcmalloc have significant advantage over gperftools tcmallocs on these single-threaded use cases?

Thanks

from tcmalloc.