Oh no, hope you're okay!

It's lime to spute.

9/9 Also, try to avoid calling things 10000 times if you can!

8/9 So how do I use Deep Profile? Well, if there’s a gap in my profile and I want to see what is there, I turn it on, manually add markers, then turn it off again. Whenever I have a profile capture taken with Deep Profile on I do not use the timing information from it.

7/9 I might then optimize function B because the profiler says it’s expensive. I'd go to profile again and it looks faster, but when I turn Deep Profile off, my performance gains will disappear because it’s just the profiling overhead I’ve reduced.

6/9 However, if B is small/fast, the overhead can take as long as the work inside function B does. Then turning on Deep Profile will make 10000 calls to function B appear more expensive than they really are.

5/9 All your function calls will now show up in your profile capture (yay!) but each of the 10000 calls will add overhead for us to record information about that call. When function B is big, the overhead doesn't matter too much.

4/9 Well, yes and no. Deep Profile is good for showing what code is running, but it’s not so good for measuring how long things take. Why? Well, let’s say we have a function A, which calls function B 10000 times. Deep Profile will add markers to each of those 10000 calls to B.

3/9 When you don’t add markers, you won’t see all your code showing up in the Profiler. There is a button in the Profiler that says “Deep Profile”. This button automatically adds markers to everything, so you don’t have to add them yourself. Seems great right?

2/9 This is as opposed to (say) a sampling profiler, which reports what is happening every so often. Why is this important? Well, it means we have to add markers to things we want to profile (with ProfilerMarker) to get them to show up.