Yes, the form has about a dozen selects, with two in particular being larger - the country and the currency fields - that probably have a couple hundred options each. I have since removed those two fields which leaves about 10 selects with about 80 options total. While these numbers fluctuate, the 12 field form was taking a little over 750ms, and the new form with 10 fields totals 375ms. So the two larger fields accounted for about half the time, but even the reduced form is still a major problem.
Regarding the reduced version, I cannot say how much the performance issue relates to having 10 selects, or to have 80 options. But it seems like 375ms is an unreasonable amount of time for this amount of work. (Just as it seems unreasonable to spend 400ms drawing those other two fields). You can see the form by visiting the site <https://www.morphmarket.com/us/> and clicking on "options" next to the search bar. I'm sorry and didn't mean to sound combative, was trying to point out that if this is the performance we expect for the default renderer, then I would have expected to see a lot more people reacting to 1.11. Which is why I believe something else must be going on. [image: Screen Shot 2018-12-10 at 8.59.32 AM.png] On Monday, December 10, 2018 at 8:40:51 AM UTC-6, James Bennett wrote: > > On Mon, Dec 10, 2018 at 6:29 AM John Lehmann <john.l...@gmail.com > <javascript:>> wrote: > >> So my takeaway from what you are saying is that no one is running a >> production site with a Django select field to render a country or currency >> option (e.g., django-countries or django-money), because either of these >> would have well over a hundred entries (and my form happens to have both). >> Instead they would be loading these options via AJAX or using a different >> widget all together like an auto-complete. (I get it that a long list is >> not the best UX but that's a bit of a different discussion). >> > > Have you profiled a country select on its own? > > Your original post suggested you had multiple large (hundreds of options) > selects in a single form that you were rendering. Whether any specific > individual select in the form is the sole culprit, or whether it's the > combination of them, is something you still haven't pinned down, and it's a > bit combative to jump to "nobody must have a country select" from that. > > In general, a select with a large set of options is going to be slower to > render. It may turn out that this has nothing whatsoever to do with your > problem, but we don't have enough information to precisely diagnose your > problem; all we can do here is give you general advice like "avoid > rendering a template hundreds of times if you can, or use a > faster-rendering template option if you can't". > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7e723ec8-be37-49cf-969e-5b484e3e5b65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
