@britzl you mentioned The Profiler while answering my last question.
I don’t really get how I should use it. It just gives generic categories like “Engine” and “Message” and it’s hard to pinpoint what exactly is causing the problem.
How should I make use of the profiler?
There is no way to see which methods are responsible for which percentage?
The profiler is useful not only when you already have a performance problem. I usually map the on-screen profiler to a key-binding to quickly toggle it on and off. While developing your game the profiler is an invaluable tool to keep an eye on the number of draw calls to make sure you’re structuring your game objects and gui nodes in a good way to maintain a steady 60 fps. The profiler is also useful to keep track of active instances of game objects and other resources to make sure you’re not leaking objects or have a bunch of objects active but off screen. Finally you should also keep an eye on the performance of your scripts while developing your game.
When you have a performance problem with either low frame rate or intermittent hitches your first stop should be the web profiler since it’s easier to work with and inspect individual frames.
If the performance problem seems to be with your scripts then it’s true that you cannot drill down in the profiler to specific scripts or functions. We’ve discussed this in the team and that kind of functionality will eventually end up in the profiler, but I don’t know when. Luckily for us all we use Lua and can thus take care of the problem ourselves 
You can easily add a script profiler using the debug library. I’ve used ProFi myself and it does the job well enough. You can start and stop the Lua profiler yourself and you get a nice breakdown of the number of function calls and time spent in each function.