ASIHTTPRequest vs NSURLConnection

[enormego]

I posted EGOImageLoading on the ASIHTTPRequest here a little over a
week ago, if you haven't seen it, you can check out the code here:
http://github.com/enormego/EGOImageLoading/

We were seeing A LOT of crashes related to EGOImageLoading when
testing the new version of one of our apps on the devices, so I
started focusing on swapping out the guts of it, to see where the
issues were.

It looks like the biggest cause of crashing was when changing
operation priority levels. I ended up rewriting the loading portion
of this entirely. This lead me to get rid of ASIHTTPRequest in favor
of NSURLConnection wrapped in an NSOperation subclass.

To test a theory I had, I added ASIHTTPRequest back in, however
instead of adding ASIHTTPRequest directly to the operation queue, I
swapped it into the NSOperation subclass I'm using to call
NSURLConnection, and called ASIHTTPRequest synchronously. The crashes
didn't come back when calling ASIHTTPRequest synchronously via a
background thread, which ultimately still created an asynchronous
call, since it's not blocking the main run loop.

My theory is that the ASIHTTPRequest run loop is far more complex when
compared to the simple NSOperation subclass I created, and there's a
lot of room for error when changing things in ASIHTTPRequest once it's
added to the operation queue. Obviously the complexity of the run
loop is needed to do all of the things that ASIHTTPRequest does, but I
think this is worth looking into, as it may be the cause of some other
crashes too.

The more concerning part about this though, is how much smoother the
app scrolled with the NSURLConnection implementation compared to the
original ASIHTTPRequest implementation. I could be wrong, but I'd
guess that NSURLConnection is just a wrapper around the CFNetwork
functions, just like ASIHTTPRequest. They're both being called via
background threads, so it shouldn't be an issue of one of them
executing on the main run loop. Is the footprint of ASIHTTPRequest
bigger than NSURLConnection? If that's the case, it could be causing
the choppier scrolling due to less free memory/processing power.

I'm going to do some more testing this week, since I like the
ASIHTTPRequest class and I much prefer working with it compared to
NSURLConnection.

[Ben Copsey]

Hi Shaun

> It looks like the biggest cause of crashing was when changing
> operation priority levels.

I'm surprised that changing queue priority would cause crashes. I'll
experiment to see if I can reproduce the problem.

> My theory is that the ASIHTTPRequest run loop is far more complex when
> compared to the simple NSOperation subclass I created,

Perhaps there are areas where performance could be improved, and it
might be possible to eliminate the main loop entirely. I guess I
should start with some tests to compare performance with
NSURLConnection.

Best,

Ben