Adding large number of items slow

[maxpower47]

When I try to add a large number of items to the drawer (couple hundred for example, use case similar to gmail app having the list of labels in the drawer) it takes a long time (minutes) to finish drawing the drawer. The logcat shows D/DrawerView: updateList() over and over.

[heinrichreimer]

An

[heinrichreimer]

Any ideas how to improve this?

[heinrichreimer]

Accidentialy closed this

[heinrichreimer]

Its probably because addItem()/addFixedItem() call updateList()/updateFixedList() each.
Have you tried adding all items to a List<DrawerItem> and calling addItems()/addFixedItems()?

[maxpower47]

Yea, I tried it with the list version, same issue.

I dug into it a little more, looking at traceview, it looks like all the time is spent in calls to notifyDataSetChanged. I see that you've set it to not notify on change in the addItems() method, but it looks like the DrawerItem.attachTo is explicitly calling notifyDataSetChanged for every item, so it ends up doing O(n^2) redraws of the list. Callling setNotifyOnChange(false) only prevents the implicit calls to notifyDataSetChanged from adding items to the adapter, it doesn't appear to prevent the explicit calls.

Once all the extra calls to notifyDataSetChanged are eliminated however, it looks like another bug crops up related to the default DrawerItem id being set as the system current time. It appears that the items are added so fast to the adapter now that many end up with the same system time, and thus the adapter removes an "old" version and replaces it with the "new" one. For example, in the following test case

        List<DrawerItem> items = new ArrayList<>();
        for(int i = 0; i < 100; i++) {
            items.add(new DrawerItem()
                    .setTextPrimary("test"));
        }
        drawer.addItems(items);

only 6 or 7 items end up in the drawer.

I don't feel like I'm familiar enough with the code to send a pull request, but hopefully this helps in tracking down the issue.

[heinrichreimer]

Thank you for this idea. I tested your approach with System.nanoTime() and it works fine.