![]() ![]() For example, maybe you can compute a running average or something as sophisticated as a Calvin filter. If there's a graph that you'd like to create but Instruments doesn't do it natively, you can synthesize the data inside your modeler. Now, another thing that you can do is create custom graphs. And perform some more extensive calculations using the modeler's working memory. ![]() This allows your modeler to keep some running totals. You can't do it in the generated case.Īnd more importantly, maintain a working memory. That's something that you can do with a custom modeler. Such as being able to fuse data from multiple input tables. They're not really there to expose the entire feature set to you that you can do with custom modelers. But these modelers are really meant to get you an Instrument up and running quickly. Now, when do you need to create a custom modeler? It's true that Xcode will generate modelers for you, in some cases specifically when you're using OS Signpost as your input. And really, what you're looking to do is add a custom modeler or you're going to be working from our sample code that's attached to the session this year, and you're going to have that project already set up. Now, at this point we're going to assume that you already have one of these projects set up in Xcode. And that all gets built into an Instrument's distribution package, which can then be installed inside of Instruments and tested. So, you also have to define the schemas that will glue all this together in the Instrument, which will ultimately view the output of your Instrument. Now, when you create a modeler, you also have to define the other pieces of that architecture as well. So, let's start with reviewing some modeling basics. And also an important topic called speculation. ![]() Now, in the process, we're also going to talk about execution and the rules engine, Cliff's rules engine. So, this year we have sample code attached to this year's session, so you can follow along with that, or use that as the basis for your own modelers. When you get to build a custom modeler, sometimes it's tough when you do it from scratch. We're going to review some modeling basics and then we're going to walk you through the process of building a custom modeler. And that will promote simplicity in other areas, specifically when it comes to the tracing code that you embed inside your logic and also the UI that you use in Instruments. And that is basically to take the complexity of your custom instrument and absorb that in the modeling layer. So, you're going to see these themes repeat in today's session. And it also keeps the UI efficient, because the UI doesn't need to know about this placeholder convention because that's all been normalized by our modeler. It saves a ton of space in the kernel's recording buffer, especially if your threads are mostly idle. Now, another kind of optimization that's made by the kernel is if the kernel samples a thread that it knows hasn't moved since the last time it samples it, instead of taking a full back trace, it just puts a placeholder backtrace into the time sample table and then our time profiler modeler picks that up, takes the last known backtrace for that, and replicates that into the Time Profile table that's viewed by the Instrument. Now, the reason we do this is because it's a lot simpler and thus more efficient to capture these primitive backtraces, and then we can fix them up in user space later inside of our modeler and therefore we keep that recording side in the kernel very efficient. So now when the kernel takes a sample of what your thread is doing, it creates or captures what's called a primitive backtrace, and it puts that into the time sample table, which is then picked up by the Time Profiler modeler, which is then transformed into a more displayable form of the backtrace, which goes into the Time Profiler table, which is ultimately viewed by the Time Profiler instrument. Now in the Time Profiler, the data that you're seeing presented in the UI is not exactly the same as being recorded by the kernel. Now modelers are important to all of our instruments including the Time Profiler up here. So in this session, what we're going to do really is just take sort of a spotlight focus on this piece in the middle, called a modeler. Now, this architecture was covered in its entirety in our 2018 session, Creating Custom Instruments. Now, within the Custom Instruments Architecture, modeling is done by this piece in the middle here called a modeler, and the modeler's job is really to reason about the raw events that are being recorded by the operating system, perform some transformations, and create the displayable events or the input to another modeler for instruments in the Air Instruments UI. I'm a performance tools engineer for Apple and this is session 421, we'll talk about modeling in Custom Instruments. ![]()
0 Comments
Leave a Reply. |