Scrolling performance optimization for ASTableView

[richardtop]

Swift 2.0, crash in ASTableView:
When I try to print out tableView.tuningParametersForRangeType(ASLayoutRangeType.Count)
I get a crash with stack trace:

2015-09-13 00:56:46.081 MyStore Staging[2432:1227873] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Requesting a range that is OOB for the configured tuning parameters'
*** First throw call stack:
(0x246d75a7 0x3269fc77 0x246d747d 0x253d25a9 0x367fbd 0x3d7bb9 0xa7063c 0xa7073c 0x27bdbb65 0x27c85785 0x27c856ad 0x27c84c31 0x27c8496b 0x27c846d1 0x27c84669 0x27bd9047 0x27602dcd 0x275fe7b9 0x275fe641 0x275fe027 0x275fde31 0x27bd1485 0x2469e275 0x2469b959 0x2469bd5b 0x245e8b51 0x245e8963 0x2bb251a9 0x27c3ac91 0x99cd8 0x32c48aaf)
libc++abi.dylib: terminating with uncaught exception of type NSException

Accessing and setting any other tuning parameters works fine.

[appleguy]

This is expected. The Count is just that--the total number of valid options if you are iterating over the range types. They are zero indexed, so the value of Count is not a valid index.

There are some Apple APIs set up this way too.

Sent from my iPhone

On Sep 13, 2015, at 12:59 AM, Richard Topchii notifications@github.com wrote:

Swift 2.0, crash in ASTableView:
When I try to print out tableView.tuningParametersForRangeType(ASLayoutRangeType.Count)
I get a crash with stack trace:

2015-09-13 00:56:46.081 MyStore Staging[2432:1227873] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Requesting a range that is OOB for the configured tuning parameters'
*** First throw call stack:
(0x246d75a7 0x3269fc77 0x246d747d 0x253d25a9 0x367fbd 0x3d7bb9 0xa7063c 0xa7073c 0x27bdbb65 0x27c85785 0x27c856ad 0x27c84c31 0x27c8496b 0x27c846d1 0x27c84669 0x27bd9047 0x27602dcd 0x275fe7b9 0x275fe641 0x275fe027 0x275fde31 0x27bd1485 0x2469e275 0x2469b959 0x2469bd5b 0x245e8b51 0x245e8963 0x2bb251a9 0x27c3ac91 0x99cd8 0x32c48aaf)
libc++abi.dylib: terminating with uncaught exception of type NSException
Accessing and setting any other tuning parameters works fine.

—
Reply to this email directly or view it on GitHub.

[richardtop]

@appleguy thanx!
So seems that there is only two parameters - preload and render. This helps a lot 👍

[appleguy]

Yes, that’s right, although I am about to add the Visible range in the next couple weeks — and have dreams of others :)

Be sure to let me know if you have any questions about ASDK! GitHub issues are a fine way to do that, or post in Paper Engineering Community (Facebook) or the AsyncDisplayKit group (Google Groups)

On Sep 13, 2015, at 10:29 PM, Richard Topchii notifications@github.com wrote:

@appleguy https://github.com/appleguy thanx!
So seems that there is only two parameters - preload and render. This helps a lot

—
Reply to this email directly or view it on GitHub #649 (comment).

[richardtop]

Thanks! Looking forward to VisibleRange feature as may help in tuning scrolling performance on slower devices.

[appleguy]

It would be tremendously useful to me if you’d be interested in writing up a little bit more on what you’d want to do with the visible range, and other feature requests / problem areas with ASDK in general. A large amount of work is being done on it right now, and I’m in the design stages of a likely-significant overhaul of the working range system.

In particular, what kind of performance-tuning stuff might you be able to do with the visible range?

Another feature you might be interested in - “synchronous, concurrent rendering” - a mode that when enabled, prevents any un-rendered content from being scrolled onscreen. UIKit does this 100% of the time, but 0% of the time performs preloading. The cool thing with ASDK is that 90%+ of the time, preloading will be finished and no blocking will occur; in the other cases, the main thread would only be blocked for the remainder of the already-started rendering. Awesomely, even if you were to disable the working range completely (0 leading / trailing screens), it would still be much faster than UIKit: different nodes in each cell will render concurrently on all cores while the main thread waits! How sensible relative to using the main thread itself :).

    — Scott

On Sep 13, 2015, at 10:50 PM, Richard Topchii notifications@github.com wrote:

Thanks! Looking forward to VisibleRange feature as may help in tuning scrolling performance on slower devices.

—
Reply to this email directly or view it on GitHub #649 (comment).

[richardtop]

Scott, sorry for late reply.

From what I've figured out, the screen stalls occur when image is being rendered. So, lets say, if you have a bunch of images with different layout and they have to be fetched from the network, there are some glitches, probably, because of some CPU power is wasted on image decoding etc.

So what I would like to use is somehow stop decoding while user scrolls and start once scrolling is completed.

Of course, the issue with screen stalls affects mainly old devices (i.e. iPhone 4S, iPad 3), everything scrolls smoothly on, for example, 6+.

[appleguy]

What classes are you using to contain the images? The behavior you've described would definitely be the case if you are using UIImageView anywhere, but it should not be the case with ASImageNode (or ASNetworkImageNode, ASMultiplexImageNode). These are tuned such that even on an iPhone 4, with a slow single-core processor, ASDK can achieve 60FPS while scrolling through large images.

I'd love to help you analyze a Time Profiler trace (from Instruments) if you can capture the phenomenon. Since uploading files can be tough, maybe you can start by taking a quick trace (just 10-30 seconds of experiencing the issue), and then paste here a screenshot of the top costs being charged to the main thread during that period (e.g., after application startup, just the scroll session highlighted).

Thanks @Richardoti, looking forward to figuring it out!

[richardtop]

So, the trace looks like this:

ASNetworkImageNode is being used, without any caching. But if downloaders is being implemented (Kingfisher), no difference in performance. The performance drop is only noticeable on 4S and iPad 3, in addition, other social network apps have such stalls sometimes as well, so I don't think it is related to AsyncDisplayKit, but more to the slow devices and complex views.

[appleguy]

The trace doesn't seem to show any rendering, so unless it's further down in the trace, it doesn't look like display / decoding of the images is to blame — right?

Although there is always some overhead from UITableView (even with ASTableView), you can reduce the trace above by making use of .isLayerBacked or .shouldRasterizeDescendents. Even if you need touch handling on individual elements of your cell, try flipping on .shouldRasterizeDescendents = YES on your ASCellNode and run it again. There are some tricks / suggestions I can give on how to be able to do event handling even with those options enabled, but it would be much easier to discuss if you could share a screenshot of your app, or a sketch of it on a napkin :)

[richardtop]

Adding shouldRasterizeDescendents. greatly improves performance, but breaks all the layout.
The app itself is a closed project, but I think "Facebook-like timeline" describes idea at its best.
The core timeline part is opensource and is available here:
https://github.com/hyperoslo/Wall

The scrolling issue is reproducible in InfiniteScrolling sample.
Interesting part is that when I try to scroll fast, the timeline scrolls quite snappy, but when I try to scroll with a moderate speed (inertial scrolling in both cases) and timeline starts loading attachments and performing layout screen stalls become more noticeable.

After I added shouldRasterizeDescendents to the most layout-intensive elements of the posts the scrolling performance became extremely fast and snappy, although layout has changed.

Also, I would like to ask about image cache configuration:
for ASNetworkImageNode there are two properties with corresponding initializers: cache and downloader.

I implemented ASImageDownloaderProtocol to forward all image download requests to Kingfisher cache library (but it can be any other library as well). So, whenever ASNetworkImageNode tries to get an image, it always ask Kingfisher. How does it affect performance? Should I implement cache as well or that property is only for convenience?

[appleguy]

@Richardoti forgive me if I asked this, but what version of ASDK are you running? There are several fixes to layout with shouldRasterizeDecedents that went in around the time of the last 1.2.x releases, and I'm not sure if all of them were in 1.2.3. We were considering a 1.2.4 but it did not happen, so they may only be complete in the master / 2.0 Beta branch.

I have not had time to release an actual 2.0 Beta branch, but master is very stable at the moment (the notable exception being certain types of more complex batch edit operations with ASTableView, which are still better-handled in master than 1.2.3). As we continue the discussion to get to the bottom of the issue, can you make sure your podfile is pointing to master and retry your test of rasterization?

[appleguy]

@Richardoti thanks for the link to the project — that is really awesome! I would love to get it running. I got InfiniteScroll set up, with pods installed, but it crashes when I launch the app saying there is no JSON file for the english locale. Do you have a local fork that I could run?

The behavior you describe is interesting and certainly useful to help debug the problem (fast scrolling is smooth, but slower scrolling is choppy). This suggests to me that it /could/ be the image downloader or another system that is contributing to the frame drops. It may also be ASDK, although I have not yet seen that behavior with ASDK in quite a few different apps.

I'll try to respond more quickly, but it's up to you if you'd like to continue debugging one step at a time or if you prefer I get set up with a working version of the app to proactively debug the issue. I really would like to fully understand and fix it with you, so either way is fine to me. Even if we fixed the layout of rasterization, and that fixed your issue, I'd love to see profiles of the slow case.

The image cache will mainly impact users revisiting images after they were initially downloaded, and memory usage. In general an app should have a way to move images from memory into disk cache, and also manage the purging of the disk cache appropriately — otherwise there is a tendency to want to cache more in memory, which 1) puts the app closer to being evicted by the system, which is not always signaled before it happens; 2) shuts down other processes the user has open, slowing them down. The symptom however would be greater LOAD TIMES for images, and to my knowledge should not have any impact on frame rates.