SlimTune Plans
I had to sit down and figure out exactly what to do about SlimTune. People really, really like that little thing, which is amazing for something I put together in six weeks. It doesn’t deserve to die, so I’m going to make sure it doesn’t. That said, it looks like it will be a while before I get back to it. January, to be exact. Unfortunately, I need to buckle down and finish my degree right now, and I can’t really afford to commit to a side project.
That’s the bad news. The good news is that I haven’t stopped thinking about the project, and I’ve figured out how to do some really sweet stuff. Let’s recap. The current release of SlimTune is a purely sampling based profiler. The goal is to enable instrumentation and hybrid modes for public use. They actually already work, except the data is thrown away by the frontend. I’ve been unsure of how to collect it in a useful way, but I’ve got some ideas now that will give you some serious detail. Min/average/max will be there, but who cares? I can give you a graph with timings, showing you the actual characteristics of the function. So if it often takes 5ms or 50ms, but nowhere in between, you’ll see two spikes at 5 and 50. The average might be 30ms, but that’s basically a bogus number in these situations.
I’ve also got some UI improvements scheduled. Probably chief among them is to fully enable custom visualizer plugins, so you can throw together your own views of the data. I’d really like to enable some kind of graphing support, but we’ll have to see how that goes. It’s tricky to find a chart control that also has favorable distribution terms. I was using MS’ chart control for the teaser photos, but it really sucks — or at the very least, I don’t understand how to use it the way I want to. Things get sized very strangely, for example. I’ll figure something out.
Oh, and people are practically begging for a way to save and load launch configurations. I promise you, that’s top of the list. It annoys me too. I did it in six weeks, remember? It will be fixed.
Now, here is the important bit. For those of you who are interested in SlimTune, I have a request! File issues against the profiler for anything you want. And I don’t just mean bugs. UI and other feature requests are welcome! You can even request things I’ve promised I will do. That’s totally fine. Hit me with everything you’ve got people! That way I know what’s most important to YOU, not me.
SlimTune Profiler Update
You may have noticed that the profiler’s development is completely frozen. No this isn’t an accident, and no it’s not discontinued or finished. I’ve got so much in store for it. The problem is that when I get into my projects, I get really immersed. Keeping up the pace on SlimTune basically meant SlimDX’s August release would never get done; I’m obsessive like that. So I made a conscious decision to freeze SlimTune until the next SlimDX release was out. (Also classes were starting.) That freeze was only supposed to last two weeks or so.
And if you keep track of what’s happening in the DirectX world, you can guess that I’ve been screwed over pretty solidly on that one. I’m not sure when I’ll actually be able to get moving on SlimDX, so I may as well bring SlimTune back to active development. Initially, I had intended to discontinue the 0.1 release series and step to 0.2, which was going to provide more profiler modes. However I got some good feedback on the 0.1.5 release that I’d like to incorporate a release, so I’ll start by putting out a 0.1.6 that will basically clean up a few bugs and inconveniences in the current release.
As for the 0.2 release series, let’s see what happens. Instrumentation is actually pretty close to ready, so maybe I’ll get that out the door and throw in some other support functionality too. There’s some prototyping happening with regards to support for native code as well, so who knows. Maybe there will be an initial implementation of that available, too. I’ve got a lot more invested in this project than I think anyone realizes. Don’t think I’ve given up.
P.S. Last I heard, the DirectX SDK was going to be released last Friday. So I have no earthly idea what’s going on.
LATE BREAKING NEWS! August 09 DX SDK is out!
SlimTune Profiler 0.1.5 Released!
Let’s recap. For about two months now, I’ve been working on a brand new profiling tool for .NET, C#, CLR, and all that jazz. It’s open source, completely free, and supports frameworks 2.0 and later (no 1.x, sorry). Some of the notable features include remote profiling, real time results analysis, and multiple visualizers. Today, the first public release, version 0.1.5, is available to the public.
Project Homepage
Direct Link to Installer
Although this is still an early version, it is already quite capable. It supports sampling mode profiling for both x86 and x64 applications, and provides views that will be familiar to users of NProf or dotTrace. Speaking of NProf, it’s my belief that this completely replaces it for .NET 2.0+, with a better UI and more features too. (And a far more lenient source code license as well.) There is still a lot to come, of course, but with this release I finally feel that this is ready for the general public.
I’m looking forward to getting lots of feedback, both positive and negative, and I hope that this is a useful tool for everyone.
(P.S. If you want to build from source, you’ll need to do it with a non-express version of VC++ 2008 SP1 and VC# 08, with a full boost installation. Also install the SQL Server Compact redist, which is in the repository under trunk\install\ExtraFiles.)
SlimTune’s Hybrid Mode
I decided to try out the dotTrace Profiler, which runs $200 for a personal license and $500 per developer for organizations. IOW, it’s expensive. That $200 license makes it the cheapest of the commercial options, and I ran the trial on one of my games. They have some nice UI touches I like. The data is valuable as well — I would not have guessed that my MainGame.Update function takes five billion percent of total program time.
Generally speaking, profilers operate in one of two modes: sampling (statistical), and tracing (instrumenting). Sampling operates by suspending the process at high frequency and examining the program state. It converges to a decent overview of where your code is spending time, but it doesn’t produce meaningful timing information. The frequency simply isn’t high enough. Tracing injects calls to the profiler every time a function is entered or exited, allowing it to monitor the complete progression of your code. You get accurate results with fairly reliable timings, but it’s incredibly slow. (Oh, and it crashes dotTrace. People pay for this?)
I’ve been looking at doing a hybrid mode since the beginning of the project; I finally came up with a concrete approach when a friend gave me a rough overview of SN Tuner, the profiler for the PS3. The idea is fairly simple: you don’t generally want tracing-level accuracy for the vast majority of the code. All you really need is an overview, which sampling does a good job of, and then tracing when you’re focusing on one specific piece. You also don’t really need detailed profiling of framework code (everything in System, for example). Although I’m still working on the front-end, SlimTune is now able to do this type of selective instrumentation at runtime.
Using it is pretty simple. When you start up the target, select Hybrid in the SlimTune UI. This will cause the program to run in sampling mode, and you’ll get your overview results. Then, you can select a function from the overview and ask it to be traced, and then results will flow in from that function and its children only. You can also turn it off again, and you can ask for entire namespaces to be skipped in either tracing or hybrid mode. Hybrid mode is a little slower than sampling overall, but it allows you to get very detailed results without the huge performance hit that normally accompanies that level of detail.
Internally, it’s a little tricky to pull this off but it’s not too bad. I discovered early on that taking a lock on the function hooks is hideously expensive, even at zero contention. I use a few lockfree tricks to get the necessary data much faster. It’s also very important not to let the sampling profiler attempt to sample inside the hooks, as this leads to some nasty deadlocks; again, lockfree code is used to lay out some unsafe zones that the sampler can detect and avoid. SuspendThread is one messy son of a bitch.
So there are at least three features I’m giving you for free which a five hundred dollar competitor doesn’t have. Sure they have a much cleaner interface, VS integration, memory profiling, and so forth…but I’ve only been doing this for a month. Kinda makes me wonder. Oh, and guess what I spent the last day or so doing…
SlimTune’s NProf Style and Pie Visualizers
SlimTune’s UI supports pluggable visualizers. What I realized was people were going to want to see their data sliced in different ways, and there would be no sane way to anticipate all those needs, let alone fuse them into a single viewing style. You’ll actually be able to drop in .NET assemblies of your own as plugins and have the option to view the profiling data using YOUR plugins, or the ones I ship. Multiple plugins at once on the same data? Check. Real-time view? As long as the plugin supports it. Remote profiling? Absolutely check.
I spent today working on the support for visualizers, and threw together an NProf style visualizer. It’s sampling-only, doesn’t handle real time yet, and generally a bit rough around the edges. But seeing as how I was typing in SQL by hand before, this is a pretty useful step up. It looks pretty decent, I think:
And then there’s this thing that took two or three hours, is a pain in the ass to navigate, but does update in real time:
Remote Profiling will NOT be secure in SlimTune
At least, not to begin with. There are some drawbacks to not being a security professional, one of which is that I have neither the qualifications nor the experience to do a proper security analysis of the profiler backend. Since I can’t audit the backend for security, it will be considered insecure, and that’s that.
The practical result of this is that allowing uncontrolled remote connections to the profiler will be incredibly dangerous. I am planning to include a setting that disallows connections except from localhost. However, if you are actually using remote profiling on something that might be attacked, it’s critical to make sure it is behind a firewall that will not allow arbitrary connections.
Eventually it should probably allow you to set a username and password for connections, but that’s again something that takes some care to implement properly and I’d rather not be the one doing it. In any case, that’s functionality which will come much later. Sorry if secure remote profiling is high on your list.










