gperftools
Main gperftools repository (by gperftools)
minitrace
Simple C/C++ library for producing JSON traces suitable for Chrome's built-in trace viewer (about:tracing). (by hrydgard)
gperftools | minitrace | |
---|---|---|
4 | 1 | |
8,537 | 378 | |
0.6% | 1.1% | |
9.4 | 2.8 | |
about 2 months ago | 3 months ago | |
C++ | C++ | |
BSD 3-clause "New" or "Revised" License | MIT License |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gperftools
Posts with mentions or reviews of gperftools.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-05-20.
-
I find it's not possible to do serious C/C++ coding on latest macOS
For profiling you are right clang has no -pg that works. But there are options, since clang supports PGO the fprofile flags could be what you need. they will generated a profraw file for you. There is also gperf tools which work for more than just linux. https://github.com/gperftools/gperftools
-
Why So Slow? Using Profilers to Pinpoint the Reasons of Performance Degradation
Because we couldn't identify the issue using the results we got from Callgrind, we reached for another profiler, gperftools. It's a sampling profiler and therefor it has a smaller impact on the application's performance in exchange for less accurate call statistics. After filtering out the unimportant parts and visualizing the rest with pprof, it was evident that something strange was happening with the send function. It took only 71 milliseconds with the previous implementation and more than 900 milliseconds with the new implementation of our Bolt server. It was very suspicious, but based on Callgrind, its cost was almost the same as before. We were confused as the two results seemed to conflict with each other.
-
Is there a way I can visualize all the function calls made while running the project(C++) in a graphical way?
gprftools (https://github.com/gperftools/gperftools) can be easily plugged in using LD_PRELOAD and signal, and has nice go implemented visualization tool https://github.com/google/pprof.
-
How do applications request for RAM from the CPU?
Google's tcmalloc
minitrace
Posts with mentions or reviews of minitrace.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-06-15.
-
Is there a way I can visualize all the function calls made while running the project(C++) in a graphical way?
I propose you to use something like Google Chrome traces. But you need to annotate the source code. Here is a lib that can be helpful https://github.com/hrydgard/minitrace
What are some alternatives?
When comparing gperftools and minitrace you can also consider the following projects:
pprof - pprof is a tool for visualization and analysis of profiling data
jemalloc
massif-visualizer - Visualizer for Valgrind Massif data files
tracy - Frame profiler
mimalloc - mimalloc is a compact general purpose allocator with excellent performance.
gprof2dot - Converts profiling output to a dot graph.
Sourcetrail - Sourcetrail - free and open-source interactive source explorer
valgrind-macos - A valgrind mirror with latest macOS support