Matthew, thanks for the note. Yes I do use fragment caching in places, though it's a bit tougher here because some of these inputs, while simple, are both populated (option sets) and initialized (defaulted) based on the user and the URL. That being said, it's probably still the easiest workaround. Despite the large number of permutations this could create based on all the parameters, I expect that the vast majority of requests could be satisfied from a couple of cached templates.
These are the two reasons why this change hit me harder than most perhaps. First, due to the its ubiquity of the form (being present on every page of my site) and second due to its dynamic configuration (thus being harder to cache). That being said, no Django site has more Python than mine <https://www.morphmarket.com/us/>... except maybe IG and Pinterest... though this issue is slowing it to a slither. ;) On Monday, December 10, 2018 at 9:32:02 AM UTC-6, Matthew Pava wrote: > > I vaguely remember having this issue when I moved to Django 1.11. It was > frustrating. I have thus far refused to move over to Jinja, and I just use > autocompletes for my large select widgets. > > > > There is also the possibility of using template fragment caching. Wrap > the select in a cache block, and it will loaded into memory once. See > https://docs.djangoproject.com/en/1.11/topics/cache/#template-fragment-caching > . > > > > > > > > > > > > *From:* django...@googlegroups.com <javascript:> [mailto: > django...@googlegroups.com <javascript:>] *On Behalf Of *John > *Sent:* Monday, December 10, 2018 9:19 AM > *To:* Django users > *Subject:* Re: Poor Performance for Form Rendering In Django 1.11 > > > > 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> 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...@googlegroups.com <javascript:>. > To post to this group, send email to djang...@googlegroups.com > <javascript:>. > 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 > > <https://groups.google.com/d/msgid/django-users/7e723ec8-be37-49cf-969e-5b484e3e5b65%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/ce3c98a1-2858-450d-8468-08bc15d91242%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
