Increased default maxConcurrentOperationCount, fixes #527

[MrAlek]

The default maxConcurrentOperationCount is set way too low in the image downloader (see issue #527). By increasing it, table/collection view performance is drastically improved. Especially when downloading images of mixed file sizes, as in the demo project.

[bpoplauschi]

I think this is a value people should set on their own. Our default value must be a middle one.

[MrAlek]

Still, a good default value is one that fits the most common use cases and loading images in cells is arguable on of the top ones.

People are having performance problems because it is difficult to draw the conclusion that the maxConcurrentOperationCount needs to be set higher. Myself, I nearly opted out of using SDWebImage when benchmarking it against my regular network library before finding out that there weren't enough concurrency.

Would you feel more comfortable with a lower value, like 6?

[rs]

Ok for me

[bpoplauschi]

I agree as well.

[MrAlek]

Lowered it to 6

[bpoplauschi]

Thanks for the quick turnaround. Merging

[rromanchuk]

Guys, did you profile this change before making it? It should really be the responsibility of the client to cancel requests that are no longer valid (cell goes off screen) or manually modifying this default if their application best fits a large number of concurrent connections...like a table view with many small images.

However, changing a very reasonable default of 2 to 6 could have drastic consequences for an application that is downloading very large images. Imagine what this could mean in terms of memory pressure for a user that has a fast connection and downloading full screen retina images.

This change may have contributed to the 15 or so tickets that are currently open due to extreme memory pressure SDWebImage is putting on devices

[MrAlek]

I would say that applications that concurrently shows many very large images is not a typical use case compared to images in table & collection views. One should optimize for the common case. If you're queuing up several full retina images, it's not wise to decompress all of them before actually showing them anyway.

The memory issues in SDWebImage have been around since long before this fix and are related to live allocations building up over time, not temporal spikes, why this change doesn't affect those issues.