[TIMOB-644] table view with large data sets are very slow
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2011-04-17T01:53:47.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 1.5.0 |
Components | iOS |
Labels | n/a |
Reporter | Nolan Wright |
Assignee | Blain Hamon |
Created | 2011-04-15T02:33:34.000+0000 |
Updated | 2011-04-17T01:53:47.000+0000 |
Description
Base UI => Views => Table Views => Table with Controls
this is very slow to load. this is also a customer issue
Comments
- Blain Hamon 2011-04-15
Okay, it's the loading itself that is slow. Looking into this and the good news is that it's not creating unnecessary views. After adding a timestamp feature, the time stamps are such:
[TIMESTAMP] 291851846.531215 Starting Group 0 [TIMESTAMP] 291851847.362943 Starting Group 1 [TIMESTAMP] 291851848.180457 Starting Group 2 [TIMESTAMP] 291851849.009998 Starting Group 3 [TIMESTAMP] 291851849.844547 Starting Group 4 [TIMESTAMP] 291851850.683528 Starting Group 5 [TIMESTAMP] 291851851.655897 Starting Group 6 [TIMESTAMP] 291851852.515305 Starting Group 7 [TIMESTAMP] 291851853.381860 Starting Group 8 [TIMESTAMP] 291851854.257839 Starting Group 9 [TIMESTAMP] 291851855.153160 Creating table view [TIMESTAMP] 291851855.293800 Adding table view
Meaning that each group of 40 rows took about 0.8 seconds. In comparison, the table view creation was fast, and after adding, the result was maybe half a second or less. In other words, something along the proxy creation or javascript running is the performance hit.
- Jeff Haynie 2011-04-15
yeah, i think this might be related to incorrectly placing the proxy property creation on the UI thread - which is should not be in construction time.
- Thomas Huelbert 2011-04-15
resolved during the 1.4 release - that said, I will compare the performance of this test case on 1.3 vs 1.4 and log a bug if the perf is lagging on 1.4
valid, has testcase