Mesh
gperftools
Mesh | gperftools | |
---|---|---|
6 | 4 | |
1,756 | 8,498 | |
0.5% | 0.6% | |
6.3 | 9.4 | |
5 months ago | 14 days ago | |
C++ | C++ | |
Apache License 2.0 | BSD 3-clause "New" or "Revised" License |
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.
Mesh
-
Spotting and Avoiding Heap Fragmentation in Rust Apps
I'm not sure if it's widely used, but Mesh is a C/C++ library that can recover from memory fragmentation. The YouTube video in the README is a great watch.
-
Compacting the Uncompactable: The Mesh Compacting Memory Allocator
From 2019. Here it is on Github: https://github.com/plasma-umass/Mesh
-
Bizarre memory leak caused by tokio runtime
With everyone talking about memory fragmentation, I'd like to mention Mesh, an allocator that can compact aka defrag the heap without any help from the program or compiler. Here's the talk explaining it, "Compacting the Uncompactable" by Bobby Powers.
- Reference Count, Don't Garbage Collect
-
How do applications request for RAM from the CPU?
Mesh by Bobby Powers
gperftools
-
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
What are some alternatives?
jemalloc
pprof - pprof is a tool for visualization and analysis of profiling data
mimalloc - mimalloc is a compact general purpose allocator with excellent performance.
memory - STL compatible C++ memory allocator library using a new RawAllocator concept that is similar to an Allocator but easier to use and write.
massif-visualizer - Visualizer for Valgrind Massif data files
o1heap - Constant-complexity deterministic memory allocator (heap) for hard real-time high-integrity embedded systems. There is very little activity because the project is finished and does not require further changes.
rmm - RAPIDS Memory Manager
tracy - Frame profiler
snmalloc - Message passing based allocator
minitrace - Simple C/C++ library for producing JSON traces suitable for Chrome's built-in trace viewer (about:tracing).