During all the time I have been here until now in Berlin, I always said what great and awesome weather we have. Since yesterday this has changed a little bit.
Stupid me was to lazy to go shopping until now. But since the last half hour the sky changed to this:
Let’s just hope that it will cool earth down… Yesterday it rained for 10 minutes, so the only effect on this was huge humidity.
That is what Ziltoid asks for to get the ultimate cup of coffee. But no, this is no post about rock music, neither about one of the most awaited album for me since some time. This time I want to go further on talking about profiling, especially announcing that version 0.01 (wow impressive number ) of my profiling application is available.
Some of you already might have recognized, that there is a new section on this page called Software. Its main target is, well of course, hosting some of the stuff I develop in my spare time. More will come, but it is a start at least.
If you want to recall my previous post about this topic, take a look here , here and here. Because most of the theory is already said there, I will not go that deep again. Additionally I will not talk about UI design because at first the Kaldile UI is not the most intuitive (I simply love this word) one, and second I guess you all know how to make an interface, most of the readers far better than me.
So, in theory all stayed the same like with the previous attempt. The difference for now is, that the kprofile.lib does nothing else than simply sending messages to a listener application about what is going on. Before it was trying to resolve the function name itself. This has the big advantage, that the profiler takes only a few clocks and your profiled application can continue doing its work. For this attempt I am using now SendMessage(). If you compile the lib with the ASYNCHRONOUS_SEND define set, it will use PostMessage() instead. PostMessage is an asynchronous message sending way, which might cause a lot of problems. For instance take an application which has many functions being called, kprofile will send a message for each enter and leave event. The message queue of the listening application will get full very very fast. Unfortunately kprofile does not know that, neither does the listener know what is going on and the messages get discarded. Because of that the logic in the listening app screws up and fails from that point on. But nonetheless I kept the define in for one reason: If you want to analyze some heavy stuff happening in a few functions, PostMessage is the much faster attempt. Additionally if you use UI it will stay much more responsible as kprofile does not need to wait for delivery of the message. One last note on the function amount being called. Always remember that inlined functions get profiled also. This is just a hint to give you an impression how fast the function stack might increase in a profiling scenario.
The listening application itself (kaldile) is not spectacular at all. In its eventmanager it checks for messages been arrived about profiling, sorts them and analyzes the results. You can turn on on-the-fly parsing, which is something I did during all the time. For statistics there are currently two result views, a treeview showing you the path your profiled project went along and a call statistics, which highlights how many times a function has been called and how long it took in average.
Finally I want to say something about the issues with the code. I still use the DbgHlp SDK available in the platform SDK done by Microsoft. It works very fine for me, I simply load the symbol table into the listening application and check for matching function names to be written into the result views. But they have more than one issue. The biggest concern about it is that you might get into trouble as soon as the profiled application quits and the symbol table loaded gets invalid. This only happened one or two times here, but you cannot profile something which closes in faster than a few clocks. A simply HelloWorld application will most probably fail to be profiled. How do other profiling application resolve this, you might ask. My guess is (well, I am pretty sure about this), that they parse the pdb file being generated, when you compile your project in debug mode. You can get some tutorials on how to parse these files, for instance here. In this article you are able to see, that the file is structured as a file system with lots of internal logics. To be honest, I could not be bothered to write an implementation on my own. Unfortunately none of the implementations I found in the internet did work here on my machine. But if you are willing to write one or you already did, it is very easy to apply it to Kaldile. Simply take a look at the symbolparser.cpp file and replace the few locations by your implementation. This would fix above issues in a very polished way.
I hope that the application will help you, when you need something like this. In theory the TODO list is very long and might get published at one point. I guess most people want to save the results or print them, so this is one of the first things, I should take care of…