> 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?
> 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.
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.
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.
Well, it's not really an idea. It is what HeapTrack and MTuner do. You install them, inspect the result, fix the worst offenders, repeat. There isn't much to it.
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.
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.
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
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.
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?
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..
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.
" 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 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.
34 comments
[ 4.2 ms ] story [ 70.5 ms ] threadI 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?
https://github.com/KDE/heaptrack
edit: typo
Seriously this is another good app in the arsenal.
https://raw.githubusercontent.com/milostosic/MTuner/master/i...
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.
Considering GNU Make is not itself available in Windows and you should install MinGW for getting make.
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
UNIX is more than just GNU/Linux, and Windows compilers are more than just Visual Studio.
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 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.
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.