12 Answers

• I had some issues with custom tableviewrows and images,
  I wrapped each element in a view then added the view to the row, And that just about cleared up my performance issue.

  However your example looks a lot simpler than my rows were.

  Mine also was Android, But just thought i'd mention it

• Okay, I did a small experiment. Here is my small sample code (all in app.js):

  Titanium.UI.setBackgroundColor('#000');
  var win = Titanium.UI.createWindow({backgroundColor:'#ff0'});
  var tableView = Titanium.UI.createTableView({});
  win.add(tableView);
  win.open();
  for (var i = 0; i < 3000; i++) {
      tableView.appendRow(Titanium.UI.createTableViewRow({title:'row #' + i}));
  }
  

  A loop with 1000 elements takes about 3 seconds to display the table. With 2000 elements it is about 18 secs and with 3000 it takes about 1 minute before anything is displayed. This is in the iPhone simulator. Times on the iPhone 3GS are even worse (I did not measure it with this example).

  Changing the last lines to the following displays the table almost immediately in the simulator with 3000 lines but still takes about 5 secs on the iPhone 3GS. So using a data array before is definitely better but still not good enough on the real device.

  var data = [];
  for (var i = 0; i < 3000; i++) {
      data.push(Titanium.UI.createTableViewRow({title:'row #' + i}));
  }
  tableView.setData(data);
  

  Since I am creating sections depending on the data and an index it gets even worse.

• there is a bug already in the lighthouse webapp, which deals with this problem, however it was moved to a future release last week. i really hope this will be fixed soon …

• Is there any information on what the bug is and how it could be fixed? Maybe by modifying the sources in the build/iPhone/classes directory of the project as a quick fix until the real one comes out? With the current performance my app is not really usable. :-(

• I don't have nearly as many rows as you do, but my load times were terrible also. One thing that helped the load time was I had to remove a background image I was using for each row. The load time was agonizing on an ipod touch. So now I check for the device being an ipod and if so don't display the background image. Not sure if this will help you, but might be a useful workaround till the bug is fixed.

• I have a tableView with over 100 rows and all is well when it comes to performance. The only minor slowness comes from loading a remote image into them - but is still fine and dandy.

  All my rows have a background image and alternating background colors (since the image is semi-transparent)

  Installed in iPhone 3GS (3.1.2) using Titanium Mobile SDK 1.3.0

  Do your table rows have unique classNames ?

• I have no background images. I started with no className property and switched to unique ones later. Did not make any difference as far as I can tell.

  I had a closer look at the number of rows and came up with 2369 rows. So "some hundred" is still correct but maybe a little understated. So maybe performance just is bad on the iPhone with that number of rows. Maybe it's the bug mentioned in one of the answers (can someone give me a link to it if there's a public view)?

  Another table has 658 rows and it builds slowly as well but it would be barely acceptable for me. This table's rows are more complex as they have an image and two labels. The images load from external URLs but you can see them loading lazily as soon as they become visible. So this is no problem at all. Also comparing the building times of the two tables it does not seem to be related to the complexity (images and labels vs. simple title properties.

  Regarding the className I am not sure what "same layout" means. If my table cells all have a title property set and hasChild is set to true, I would consider this "same layout", so I have to set the same className for all of them, right?

• I have a similar issue. Are you creating the table by pass through an array of rows at the end (data:data) or are you appending each row to the tableView as you create the row?

• To follow up on what I said earlier. My issue was that I was creating all the rows for the table before using them: I created an array of rows and used that as the table's data. I refactored my code to create and show the table first, and then to append each row as it was created, and it seems far more responsive.
  Hopefully that helps you out

  James

• I was adding it in the end via setData. I tried adding each row directly but that makes it even slower for me.

• Hmm, that's strange.. I did use an animation with the appendRow call too.. Wonder would that help? (Doubtful)

  Also,just to be sure, have you added the table view to the window and shown the window before all of the adding?

• My last sample is still valid, i.e. 3000 simple lines in a table view take about 5 seconds on an iPhone 3GS which seems to be a little slow. Maybe the iPhone just is that slow, only a pure C implementation could tell. But I discovered that the rest of the time (about 4 to 5 seconds again) is spent parsing the JSON response from the server which is used for filling the table. Sorry I did not notice that before and thought it was all due to the poor table performance.