I may just be using this program wrong, but I've been having a lot of difficulty using the C++ profiler on MacOS. There are two major issues:
I'd preferably like to see line-by-line annotations of where time is spent not just per-function. I haven't figured out how to do this.
When I look at the per-function annotations, the function annotation is so large it pushes the function name off the screen, and Instruments doesn't seem to want to let me scroll to the right. See photo.
I'm sure I'm using this wrong. Would anyone be able to help me out?
Thanks so much!
I'd preferably like to see line-by-line annotations of where time is
spent not just per-function. I haven't figured out how to do this.
Double-clicking a function in the call tree view opens the source view, which shows line-by-line statistics.
The following articles should help you interpret the data Instruments generates:
Measuring Your App's Memory Usage with Instruments
Finding the Slow Spots in Your Code with the Time Profiler Instrument
Related
I am working on a proof of concept and I need to measure the rendering time of a simple website (just a HTML document and one CSS file) 1000 times in a browser. Is there a simple and straightforward tool for this?
I know there are some highly complicated tools with an enormous learning curve, but I don't have the whole week to tinker with it. I don't need anything else just the rendering time, exactly as Chrome's Performance tool displays it in milliseconds, then calculate an average.
If someone could tell me how to find the total rendering time of the page in the (quite enormous) JSON output of the Performance tool, I'd be happy with that. I can have a macro recorder clicking the Refresh button all night. Though I guess there's a way to get it done from the command prompt - any advice is appreciated on that too!
The 'Audits' tab in Chrome's dev tools allows you to run a lighthouse performance audit, which will provide you some key metrics as defined by Google (such as time to interactive): https://developers.google.com/web/tools/lighthouse/.
You can run it from the command line too, which should make it somewhat straightforward to repeat it as needed in your scenario and perhaps even integrate it as a test: https://developers.google.com/web/tools/lighthouse/#cli
I've downloaded Apple's TextEdit example app (here) and I'm a bit puzzled by one thing I see there: the TextEdit.scatterload file. It contains a list of functions and methods. My guess is that it provides information to the linker as to which functions/methods will be needed, and in what order, when the app launches, and that this is used to order the binary generated by the linker for maximum efficiency. Oddly, I seem to be unable to find any information whatsoever about this file through Google. So. First of all, is my guess as to the function of this file correct? And second, if so, can I generate a .scatterload file for my own macOS app, to make it launch faster? How would I do that? Seems like a good idea! (I am using Objective-C, but perhaps this question is not specific to that, so I'm not going to tag for it here.)
Scatter loading refers to a way to organize the mapping of your code in memory by specifying which part of code must be near which one, etc. This is to optimize page faults, etc.
You can read about it here Improving locality of reference (HTML)
or here Improving locality of reference (PDF).
.scatterload file is used by the linker to position code in memory layout of the executable.
Except if your app really need tight performance tuning, I would not encourage you to have a look at this.
Hello and thanks for checking out my question,
I am working on a project analysing film and visualizing the data I got from it. I'm quite new at programming and only have some basic experience in java and javascript.
For my project I want to store the db levels of a movie in a csv file, to later work with the data in processing. I couldn't find anything that wasn't too complex for me to comprehend for Mac (OSX.)
Help would be much appreciated!
Thank you.
You're going to have to break your problem down into smaller steps.
Step 1: Generating the CSV file.
There are probably a million different ways to do this, and that can be pretty confusing. But break this down into smaller sub-steps and then take those steps one at a time. Can you get a movie playing in Processing? There is a Video library that does just that. Then can you get the volume level every X seconds? You might start with a separate sketch that just prints something to the console every X seconds. For getting the volume, you might try out the Minim library. If that doesn't work, Google is your friend, and remember to keep breaking your problem down into smaller steps!
Step 2: Loading the CSV file.
Now that you have the CSV file, you have to load it into Proccessing. There are several functions in the reference that might come in handy. Again, start with an example program that just prints the values to the console. Get that working perfectly before moving on.
Step 3: Visualizing the data.
Now that you have the data in your Processing code, you can start thinking about how you want to visualize the data. Maybe a line chart that just shows the volume over time just to start with.
If you get stuck on a specific step, then try to break it down into smaller sub-steps. Create an example program that just tests one of those smaller sub-steps (also known as an MCVE), and you'll be able to ask a more specific code-oriented question. Good luck, sounds like an interesting project!
This question is not about finding out who retained a particular object but rather looking at a section of code that appears from the profiler to have excessive retain/release calls and figuring out which objects are responsible.
I have a Swift application that after initial porting was spending 90% of its time in retain/release code. After a great deal of restructuring to avoid referencing objects I have gotten that down to about 25% - but this remaining bit is very hard to attribute. I can see that a given chunk of it is coming from a given section of code using the profiler, but sometimes I cannot see anything in that code that should (to my understanding) be causing a retain/release. I have spent time viewing the assembly code in both Instruments (with the side-by-side view when it's working) and also the output of otool -tvV and sometimes the proximity of the retain/release calls to a recognizable section give me a hint as to what is going on. I have even inserted dummy method calls at places just to give me a better handle on where I am in the code and turned off optimization to limit code reordering, etc. But in many cases it seems like I would have to trace the code back to follow branches and figure out what is on the stack in order to understand the calls and I am not familiar enough with x86 to know know if that is practical. (I will add a couple of screenshots of the assembly view in Instruments and some otool output for reference below).
My question is - what else can I be doing to debug / examine / attribute these seemingly excessive retain/release calls to particular code? Is there something else I can do in Instruments to count these calls? I have played around with the allocation view and turned on the reference counting option but it didn't seem to give me any new information (I'm not actually sure what it did). Alternately, if I just try harder to interpret the assembly should I be able to figure out what objects are being retained by it? Are there any other tools or tricks I should know on that front?
EDIT: Rob's info below about single stepping into the assembly was what I was looking for. I also found it useful to set a symbolic breakpoint in XCode on the lib retain/release calls and log the item on the stack (using Rob's suggested "p (id)$rdi") to the console in order to get a rough count of how many calls are being made rather than inspect each one.
You should definitely focus on the assembly output. There are two views I find most useful: the Instruments view, and the Assembly assistant editor. The problem is that Swift doesn't support the Assembly assistant editor currently (I typically do this kind of thing in ObjC), so we come around to your complaint.
It looks like you're already working with the debug assembly view, which gives somewhat decent symbols and is useful because you can step through the code and hopefully see how it maps to the assembly. I also find Hopper useful, because it can give more symbols. Once you have enough "unique-ish" function calls in an area, you can usually start narrowing down how the assembly maps back to the source.
The other tool I use is to step into the retain bridge and see what object is being passed. To do this, instruction-step (^F7) into the call to swift_bridgeObjectRetain. At that point, you can call:
p (id)$rdi
And it should print out at least some type information about the what's being passed ($rdi is correct on x86_64 which is what you seem to be working with). I don't always have great luck extracting more information. It depends on exactly is in there. For example, sometimes it's a ContiguousArrayStorage<Swift.CVarArgType>, and I happen to have learned that usually means it's an NSArray. I'm sure better experts in LLDB could dig deeper, but this usually gets me at least in the right ballpark.
(BTW, I don't know why I can't call p (id)$rdi before jumping inside bridgeObjectRetain, but it gives strange type errors for me. I have to go into the function call.)
Wish I had more. The Swift tool chain just hasn't caught up to where the ObjC tool chain is for tracing this kind of stuff IMO.
I don't understand the output from the "Leaks" performance tool in XCode. How can I interpret this output?
The Leaks Instrument looks for blocks of memory that are not referenced from the application code.
The Table View shows the addresses of the block found in such condition.
Yes, Instruments it's not simple to use, there are many leaks apparently from the OS and/or the system libraries, the details often show over-freed blocks (?!).
Life is complex :)
Leaks is only marginally useful. A much bigger problem you will have is references which are still retained that you think have been released. For that, use the Object Allocation tool with "created and still living" checked.
If you see memory use increase over time, highlight a region and see what objects are allocated in your own code that you were not expecting.
Leaks is covered in a wonderful video of Lecture 10 of Stanford's CS 193P (Cocoa/iPhone Application Programming).
http://www.stanford.edu/class/cs193p/cgi-bin/index.php