[TIMOB-11987] iOS: TableView row management makes it drastically slow
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Hold |
| Resolution Date | 2013-02-12T23:12:57.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | iOS |
| Labels | api, data, ios, reuse, rowdata, tableview, triage |
| Reporter | Martin Guillon |
| Assignee | Shak Hossain |
| Created | 2012-10-14T16:03:30.000+0000 |
| Updated | 2017-03-21T21:16:48.000+0000 |
@martin, I think you've done an incredible job troubleshooting and outlining this problem for appcelerator. They should at least grant you the courtesy of implementing this ASAP to thank you for doing a large par of their job for them! Tableview performance is really becoming a critical issue on Ti for iOS and Android and it seems that appcelerator isn't really paying attention.
@Michal Belkin: Actually it is not as easy as it might seem. I think Appcelerator knows about the depth of the problem. But changing it now means a lot of work, and possible regressions. I do think that it is a matter that should be looked at right away as tableview is one of the most commonly used widget in apps. Also know that Appcelerator is working on getting it a little quicker (This is not the right solution and shouldnt be the definitive solution though).A [pull request](https://github.com/appcelerator/titanium_mobile/pull/3260) has just been pulled to fix a regression appeared in 2.1.3 I should also mention that things are going so much better on android! I havent had the time to go deep into the android code (keep in mind that that the tableview code is pretty complex) but will try and see the difference.
@Daniel: Sorry it took me so long to come back on this one. The pull request definitively fixed the problem. I get great performances now The only problem now is with loading as explained in the description. But this has nothing to do with the pull request itself. So my answer yes but i still dont think we should close this one. There is still something to do with the setData problem. Thanks
I can confirm this problem, I can also confirm we have been talking to Appcelerator about this for at least 1.5 years and very little was done to mitigate this. This performance issue is *alone* what singles out Ti apps from native Objective C apps, no other control/function/method which we used with Ti was that inferior to Objective C performance as TableViews.. @martin - your solution is good, exactly what I had mind...
@Moshe: I have been thinking/playing a lot lately around the tableview. The solution i present above has its problem. For example you dont really know when you can start playing with the proxy objects. I mean you expect proxy objects (your javascript interface to the view objects) to be created right on in the setData. COnsequently my approach isnt really necessary. What we need is for views NOT to be created in the setData but to be created/added in the "cellForRowAtIndexPath" method of the iOS tableview. That way loading gets crazily faster (well not crazily fast though). That's actually what the android implementation does
@Martin: what we need is for Ti stick to the same method of work as native obj c apps do. first you define a row class, then you create 5-10 rows, then create views per row for the complex row structure specific to an app. next, iOS will call us to provide data only(!) for each row drawn while reusing the same 5-10 rows created, this will provide for theoretical unlimited rows length with excellent performance. your solution provides a possible way for Ti to describe the views per row and then let iOS ask for data from the JS code, thats why I think it is one way to move forward to a native tableView implementation.
@Moshe: Yes this is what i am talking about, view creation upon use. Which is the case on android. But you need to understand that there is another level of data in Ti, which is the proxy. Think of it as the model item in native dev
These issues will be addressed in the ListView module (TIMOB-11809). Work on this module has already started and the goal is to have it ready by 3.1.0 release. Rewriting tableView to support this architecture is going to be impossible for historical reasons. Moving this ticket out of the Sprint. Will be resolved with the ListView module.
Creating a new module is not "THE" way. It might be a VERY GOOD module but the tableview still needs fixing. And it s doable
@Martin. We don't have the bandwidth to solve this as part of Q1, and it's unclear that a solution for TableView will give us the ultimate performance we need. If you would like to submit a PR for the solution you propose, we are more than happy to assist.
@Ingo: Could you contact me by mail about this?(cant find your mail) here is my mail martin.guillon@akylas.fr
Closing ticket due to the time that has passed since it was filed.