New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.listview('refresh') iterates over entire list? #6680

Closed
lightsurge opened this Issue Oct 30, 2013 · 11 comments

Comments

Projects
None yet
5 participants
@lightsurge
Copy link

lightsurge commented Oct 30, 2013

I'm finding container.listview('refresh') does work over the entire list rather than just new (i.e. appended) items?

In my use case I'm regularly appending (via ajax) a small number (5) of items. In order to style the new items, the documentation advises me to call listview('refresh'). This starts fast, and then becomes exponentially slower.

Once my list reaches a length of 200 items, on my fastest testing device (Nexus 7), I'm waiting ~7 seconds for listview('refresh') to complete, during which my list is unusable, on my slowest device, I'm waiting >10 seconds.

Is this normal behaviour? I can see the use case for needing to check for changes to items, but in my case items never change, and all this work taking place every time the list is appended is obviously a complete waste of resources and renders the list unusable.

If it is normal behaviour, is there an alternative to listview('refresh'), like listview('appended'), that just selects the items after ".ui-last-item"? Currently I have a workaround where I put appended items into a hidden list, call .listview('refresh') on that, and then move the list items into my visible list.

@jaspermdegroot

This comment has been minimized.

Copy link
Member

jaspermdegroot commented Oct 30, 2013

@lightsurge

Thanks for reporting the issue. This indeed something we have fix. We used to check for the ui-li class and only enhanced the list items that didn't have that class, but we don't add that class anymore to improve performance at startup.

@jaspermdegroot

This comment has been minimized.

Copy link
Member

jaspermdegroot commented Oct 30, 2013

We just looked into this and turned out my previous comment was incorrect. When I made the change to not add class ui-li anymore I also added new checks to prevent enhancement of already enhanced list items when the refresh method is called (86875b6 and e07be5a). So I am not sure where the performance regression in your case is comming from.

@lightsurge

This comment has been minimized.

Copy link

lightsurge commented Oct 30, 2013

At a glance from those commits it looks like it might be because I'm using autodividers? I figure this might be written so that if a list is using autodividers, the entire list is refreshed in order to prevent a duplicate divider appearing in the appended content that is already present further up the list.

If that's the case, in my workaround, where I'm appending to and then copying from a hidden list, I'm preventing this by doing:

if ($('#visible-list li').last().data('divider') == $('#hidden-appended-list li').first().html()) {
$('#hidden-appended-list li').first().remove();
}

Which is all I need to do to get rid of duplicate divider, I don't need the whole list refreshing.

Anyway, I might be wrong, I'll try turning off dividers and see if I still have the performance issue.

@lightsurge

This comment has been minimized.

Copy link

lightsurge commented Oct 30, 2013

Ok here's a fiddle:

http://jsfiddle.net/2VYxh/14/

Just crack open the console and scroll down the listview.

In my testing it went from 0.01 seconds with 6 list items to 0.3 seconds with 400.

Obviously that's nowhere near the slow-down I was experiencing, but shows that the refresh is targeting more than just already enhanced list items.

@lightsurge

This comment has been minimized.

Copy link

lightsurge commented Oct 30, 2013

Ah my last test was on my desktop machine. On my Nexus 7 the stats were more like the slow-down I was seeing in my app.

1.004 seconds with 120 items.

Edit: Forgot to mention that without autodividers it was twice as fast, but still getting increasingly slower as the list grew (0.46 seconds with 120 items). Here's my fork of the last fiddle without autodividers http://jsfiddle.net/dA8PS/1/

Edit again: Realise in my jsfiddle I was using jquery mobile 1.2, but I just tested again with 1.3 and the results were pretty much identical.

@Ruffio

This comment has been minimized.

Copy link

Ruffio commented Oct 29, 2014

What is the status on this one? Do we have a partial solution? I will be happy to test on Nexus 7 and LG G3. Just post some links...

@arschmitz

This comment has been minimized.

Copy link
Member

arschmitz commented Oct 29, 2014

So the code for this has not changed we are still iterating over the entire list. This is something we need to look at when we re-write listview in general it should not be an issue even with large numbers of elements as in general essentially nothing is done to each in the loop if already enhanced. I want to keep this open just so its not forgotten when we do get to re-writing listview.

@Ruffio

This comment has been minimized.

Copy link

Ruffio commented Dec 30, 2014

@arschmitz Should this not be labelled 1.5 as reviewing/rewriting Listview is a part of 1.5?

@arschmitz arschmitz added this to the 1.6.0 milestone Jan 9, 2015

@arschmitz

This comment has been minimized.

Copy link
Member

arschmitz commented Jan 9, 2015

@Ruffio the roadmap needs to be updated but listview re-write due to changing team amount of help and other things is going to be moved to 1.6 so adding that label

@arschmitz arschmitz modified the milestones: 1.5.0, 1.6.0 Jul 16, 2015

@arschmitz

This comment has been minimized.

Copy link
Member

arschmitz commented Jul 16, 2015

Moved this back to 1.5 we ended up getting to this as part of some other updates to listview

@gabrielschulhof

This comment has been minimized.

Copy link
Contributor

gabrielschulhof commented Jul 16, 2015

Actually, this is already fixed in 1.4.5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment