New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake: only use TCMALLOC when specified in build flags #1580
Comments
I think it should be the default, but it should be possible to turn it off. Is this not the case? |
It's just not what one would expect. (In other applications one has
This should work when the flag is correctly implemented. |
If TCMalloc is the best-performing allocator, it should be the default when available. |
Based on what benchmarks and criteria and what versions of tcmalloc/glibc? E.g. our build scripts (and Ubuntu) still use the version from gperftools and not the latest from https://github.com/google/tcmalloc. Also, TCMALLOC can be annoying at first while debugging code or running KLEE with a sanitizer, e.g.:
I really think it's odd to pick up a non-standard allocator. What if I use a very slow instrumented version of TCMALLOC just for debugging purposes on my system?! |
In my experience it works better. But I haven't run any systematic studies. |
If we are just talking about defaults, then KLEE should attempt for the optimal case given available resources. This is how KLEE deals with all other dependencies (e.g., we do not require This obviously leads to the question what we expect the optimal case to be.
Finally, I would like to propose that if tcmalloc is not expected to be better than the glibc allocator for a significant subset of use cases, we should completely remove support. |
Many show improvements for heavily threaded code - we don't have many threads.
I'm pretty sure that's not in the old version we use (as mentioned above). |
With the latest change to the build system (#1569), TCMALLOC gets pulled in when it is available on the system. I'd prefer this to be an optional dependency that gets linked only when requested.
The text was updated successfully, but these errors were encountered: