3

I have been working on tracking down a performance issue in one of our apps. What seems to happen is that sometimes a UIImageView takes seconds to render an image and, because of the way the code is written, this blocks the main thread.

I've tracked down the issue to the fact that the slow images are progressive JPEGs at retina resolutions. For whatever reason, when the file reaches a certain size, decoding the JPEG becomes a very expensive operation.

Anyway, in the course of writing a simple test application, I realized I didn't know how to time how long the draw event takes. It clearly is blocking the main thread, so I decided to just try and time the run loop iteration. Unfortunately, it ended up a bit hackish. Here's the relevant code:

///////////////
//
// This bit is used to time the runloop. I don't know a better way to do this
// but I assume there is... for now... HACK HACK HACK. :-)

buttonTriggeredDate_ = [NSDate date];
[[NSRunLoop mainRunLoop] performSelector:@selector(fire:) target:self argument:[NSNumber numberWithInt:0] order:1 modes:[NSArray arrayWithObject:NSDefaultRunLoopMode]];

///////////////

NSString* path = [[NSBundle mainBundle] pathForResource:imageName ofType:type];
self.imageView.image = [UIImage imageWithContentsOfFile:path];

The callback is as follows (more hackiness!):

- (void)fire:(NSNumber*)counter {
    int iterCount = [counter intValue];
    NSLog(@"mark %d", iterCount);
    NSTimeInterval interv = [[NSDate date] timeIntervalSinceDate:buttonTriggeredDate_];

    // We really need the second pass through - if it's less than X, assume
    // it's just that first runloop iteration before the draw happens. Just wait
    // for the next one.
    if (iterCount < 1) {
        iterCount++;
        [[NSRunLoop mainRunLoop] performSelector:@selector(fire:) 
                                          target:self 
                                        argument:[NSNumber numberWithInt:iterCount] 
                                           order:1 
                                           modes:[NSArray arrayWithObject:NSDefaultRunLoopMode]];
    } else {
        self.statusDisplay.text = [NSString stringWithFormat:@"%@ - Took %f Seconds",
                                   self.statusDisplay.text,
                                   interv];
    }
}

So, my question is, basically, how would you do this? I want to be able to drop in different images and run a benchmark to make sure I have a rough idea of how long it takes to run this. I also would like to have it be reasonably consistent and free of jitter.

Hmm, maybe I should just subclass UIImageView and record times around [super drawRect:frame]?

What would you do?

sujal
  • 1,595
  • 1
  • 13
  • 14
  • Have you ever tried this [[NSDate date] timeIntervalSince1970], get system milliseconds and imageView is loading sync on main thread, so you can get the span between start and end of the load. – Tom Jun 19 '12 at 16:33
  • I did that - the problem is that the actual drawing happens on a subsequent iteration of the run loop. I think the setImage: call just sets the pointer to the UIImage and probably just calls setNeedsDisplay or whatever, which then calls draw on the next runloop. – sujal Jun 19 '12 at 16:46
  • Yeah you probably right, i have no idea how to do it, I did an app to load many large images, and I put all codes on another thread, and use self performSelect on main thread to check if it's ready to avoid blocking main thread. – Tom Jun 19 '12 at 17:07

1 Answers1

0

You're likely trying to time the wrong part of the problem. As you suspect, the problem is most likely in the decode (and probably also in memory allocation and copying). It is not likely that the problem is in the final "drawing" step per se.

This is the kind of problem that Instruments is built for. Fire up Instruments and look for your hotspots.

As a possible solution, if Instruments tells you that decoding is what's blocking you, you may consider rendering the images onto a CALayer on a background thread before putting them into the view.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Thanks - That is indeed the solution I ended up with. This was more a thought experiment about trying to understand how long a component I didn't have source to was taking to draw. Seemed like an interesting puzzle. Useful, too. In the process of debugging my code, I needed to figure out how fast putting the pixels on the screen took, for example, to understand what the best case might be. – sujal Jul 13 '12 at 19:48
  • This unfortunately (and also somewhat fortunately) is a much more complicated question than it sounds. "Putting pixels on the screen" isn't actually done by `drawRect:`. There is a huge amount of compositing going on behind the scenes that you're just providing inputs to. So while you can time your `drawRect:` (or other individual methods), that may not tell you how long it takes to draw in aggregate. You can pull some data from the Core Animation instrument in Instrument, as well as the OpenGL instruments. On Mac you can Quartz Debug as well, but that's not available on iOS. – Rob Napier Jul 14 '12 at 01:05