MTuner is a C/C++ memory profiler and memory leak finder(github.com)
github.com
MTuner is a C/C++ memory profiler and memory leak finder
https://github.com/milostosic/MTuner
34 comments
How does that compare with the sanitizers in Clang (Memory, Address .. ) ?
Doesn't work on a Mac.
Yes, it says that in the README. Plenty of people use other operating systems, though.
> MTuner is a C/C++ memory profiler and memory leak finder for Windows, PS4, PS3, etc.
I don't see any mention of Mac at all in the Readme, and I find the "etc" part confusing. For example, I use FreeBSD. PS4 is based on FreeBSD. Does FreeBSD go under the "etc" part? If not then what does?
I don't see any mention of Mac at all in the Readme, and I find the "etc" part confusing. For example, I use FreeBSD. PS4 is based on FreeBSD. Does FreeBSD go under the "etc" part? If not then what does?
> MTuner supports Windows, PlayStation 4 and PlayStation 3
> out of the box. Additionally, any platform with GCC or
> Clang based cross compiler can easily be supported with a
> little extra work. Instrumentation API comes with full
> source code which means it’s a matter of porting a few
> routines to get it up and running on additional platforms.
It's still not clear to me.
I think it means you can use if your host platform is Windows, but you can target other platforms through cross-compiling, but it doesn't say it explicitly.
Most of them actually.
In case someone is looking for the equivalent on Linux and Mac, there is HeapTrack
https://github.com/KDE/heaptrack
edit: typo
https://github.com/KDE/heaptrack
edit: typo
I've been looking for something like this. Massif makes it look like my code is reasonably healthy. HeapTrack shows I'm doing absurd number of small heap allocations.
Is there a binary version of this tool that can be downloaded somewhere? Seems a bit of a pain to install.
Follow the link to homepage in readme, there you'll find download link to binary: http://mtuner.net/index.html#download
2 Clause BSD! Woop woop!
Seriously this is another good app in the arsenal.
Seriously this is another good app in the arsenal.
Doesn't valgrind do this?
Most of it (memcheck and massif), but good luck getting the important data out. Memcheck is fine, but massif is quite restricted as a object-level memory monitor. I can't talk for MTuner, but HeapTrack is very, very useful to track and eradicate temporary allocations (useless C++ object create when using `==` or passing by copy.
Very good. I wish you all the success.
But I have a (side) question. You are using Makefile while targeting non-nix platforms. Why? It seems to me it is the strangest combination ever.
But I have a (side) question. You are using Makefile while targeting non-nix platforms. Why? It seems to me it is the strangest combination ever.
For convenience! Make is a powerful software and GNU Make is readily available for Windows, e.g. as part of MinGW. I also actively use it for my projects, because it's just kind of always there when you need a build system and you can put together an initial Makefile real quick.
" and GNU Make is readily available for Windows, e.g. as part of MinGW."
... I don't think we have the same definition of "readily available". First you have to choose between two dozens MinGW distros, some up-to-date, some not, choose if you want to use Windows or Unix paths, etc etc.
... I don't think we have the same definition of "readily available". First you have to choose between two dozens MinGW distros, some up-to-date, some not, choose if you want to use Windows or Unix paths, etc etc.
Isn't all of these arguments applicable to CMake?
Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
Windows is a pain to program on, and MinGW alleviates that somewhat. I do use CMake though, but I still want to use "normal" clang, so I have to generate a unix makefile. I don't want to maintain two sets of build systems.
Windows is a pain to program on,
It's really not, if you know how to do it. But that goes for any OS out there. I mean, put a seasoned visual-studio-on-windows-only dev in front of a linux box and tell him to set up the build of a non-trivial application and watch what happens. Chances are pretty high the answer is 'linux is a pain to program on' :]
but I still want to use "normal" clang, so I have to generate a unix makefile
https://blogs.msdn.microsoft.com/vcblog/2017/03/07/use-any-c... it's still relatively young but seems to work quite ok
It's really not, if you know how to do it. But that goes for any OS out there. I mean, put a seasoned visual-studio-on-windows-only dev in front of a linux box and tell him to set up the build of a non-trivial application and watch what happens. Chances are pretty high the answer is 'linux is a pain to program on' :]
but I still want to use "normal" clang, so I have to generate a unix makefile
https://blogs.msdn.microsoft.com/vcblog/2017/03/07/use-any-c... it's still relatively young but seems to work quite ok
windows not being able to mix and match object files compiled in different ways is really disastrous. On linux and windows I always work in release mode. If I have problems on the linux side I can target compile 1 or 2 object files debug, relink, run and get stack traces if I need. That's all totally independent of programming environment.
That has nothing to do with Windows vs GNU/Linux, rather the compilers being used.
UNIX is more than just GNU/Linux, and Windows compilers are more than just Visual Studio.
UNIX is more than just GNU/Linux, and Windows compilers are more than just Visual Studio.
True (apart from where you say 'windows' when meaning 'msvc toolset' as pointed out). It's actually the first time I see this come up as first and only argument against msvc actually. Would be interesting to find actual stats on this, but it's possible this doesn't come up often because it's sort of a minor issue; minor in the sense that it is not a real issue for the majority of users (though that doesn't mean that if you are affected by the issue that it can't be a dealbreaker). Maybe there are more people out there used to mostly working with debug builds? Or maybe because the overhead of having to build eveything in debug mode again only becomes significant with codebases much bigger than the average?
Only for UNIX devs that don't want to learn any other way.
I am programming Windows since version 3.0, have experience across multiple types of operating systems, had a phase of my life of being a GNU/Linux zealot and where I like to spend my time is on Windows.
I live on my IDEs and there is hardly a CLI feature that can't be better done within a REPL environment.
I am programming Windows since version 3.0, have experience across multiple types of operating systems, had a phase of my life of being a GNU/Linux zealot and where I like to spend my time is on Windows.
I live on my IDEs and there is hardly a CLI feature that can't be better done within a REPL environment.
You wouldn't have to maintain two sets of build systems. You write one cmake file, and it generates unix makefiles or visual studio projects. As a windows developer, I groan whenever I find a makefile..
Impressive work, Mr Tošić! :)
I never used other memory profilers than MTuner mainly because not needing it, but also because MTuner works so well (for what I used it) I saw no reason to look for anything else: the combination of the different ways to view allocations/deallocations make for a very detailed yet uncomplicated view of your application's memory managment. E.g. first thing I noticed once was a constructor allocating 20 blocks of 8K and freeing them again just to initialize a vector, so that immediately tells you there's room for improvement there. Possibly other tools work just as well, but I can't compare.
It's also interesting just to look at all the data to figure out how exepensive some things are memory-wise. These days with the more modern C++ it's easy to forget what goes on under the hood. Nothing wrong with that per-se: C++ is usually performant enough that you just don't have to care about it at all. But if you have this typcial engineering mindset and like to know how stuff works just for the sake of it, and 'stuff' in this case is 'memory usage', then this is your tool.
It's also interesting just to look at all the data to figure out how exepensive some things are memory-wise. These days with the more modern C++ it's easy to forget what goes on under the hood. Nothing wrong with that per-se: C++ is usually performant enough that you just don't have to care about it at all. But if you have this typcial engineering mindset and like to know how stuff works just for the sake of it, and 'stuff' in this case is 'memory usage', then this is your tool.
Did anyone try it with https://developer.arm.com/open-source/gnu-toolchain/gnu-rm?
How different is this from Intel's vtune amplifier? I used vtune amplifier to get the memory profiles for some c++ code I had written before.