-
-
Notifications
You must be signed in to change notification settings - Fork 32.9k
#3202 - Large speed increases to SelectBox and SelectFilter2 #222
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
Conversation
} | ||
} | ||
box.appendChild(fragment.cloneNode(true)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you cloning here? Can't you just append the fragment?
I think there's potential for usability improvements that can be done in relation to tabindex etc but I'm not sure how people would want the form to actually behave. |
The cache ended up having race issues now that it was working quickly, but I realised that it wasn't even needed anymore anyway. I also changed the keyboard functionality to something better I believe.
|
Thanks a lot for your work. Do you think you could reproduce the same performance improvements, but also rewrite the widget with jQuery? If so, then I think it'd be a better approach to kill these two birds with one stone. See this ticket for reference: https://code.djangoproject.com/ticket/15220 |
Fixing this issue would be hugely appreciated :) I'm currently working with a project that displays 13k items in a filter_horizontal widget and the page takes 20-30 seconds to load. |
Closing this in light of @jphalip's comment above. |
Makes the "create a new GitHub repository" step clearer.
I have an admin page with two filter_horizontal widgets on it. One has almost 800 options and the other 11,500. As you can imagine it's pretty slow but also it sometimes copies the wrong selections if you have a lot of them, plus it crashes on page load in IE and Opera. The scripts in 1.4 make it even slower by using a slow jQuery selector to check if anything is selected when deciding what icons to use.
The tweaks to redisplay from #3202 will cut a second or so off of every action but the code still calls redisplay way too often which means doing anything takes 2-5 seconds. Ticket #9102 attempted to avoid redisplay but its method of hiding
<option>
tags doesn't work in Chrome.I've come up with the following which will generally transfer options instantly on my 11,500 list. It starts to slow down if you're moving stuff from side to side in bulk but it's still faster than what's currently in Django. It works excellently in Chrome, Firefox, and Safari, but Opera and IE are still slow but no longer crash.
selected="selected"
(even in a plain HTML file). So while you can use this javascript to select 10,000 options in 2 seconds your tab might crash after the form submit.