Slow admin loading

[luke3141]

I have a field of type CountryField. In the admin interface, when I use this field in the list display, it's incredibly slow to load when there are ~100 rows.

I've tried using list_select_related = ('country',), or even list_select_related = True, but there is no speedup (DDT doesn't report any extra queries with or without this - 5 in each case). However, there is significant speed increase when I use a filter (reducing the number of rows) or if I remove this field from the list display interface.

Is there any way to speed this up/cache the results?

[SmileyChris]

Odd... django-countries doesn't use any database entries. All that is stored in the db is the ISO code. Retrieving the field uses a descriptor that creates a pretty simple Country object, calling str/unicode just returns the code. Calling .name on it just references against a static dictionary of countries to return the actual name.

Not sure why you'd be seeing a large overhead. To be clear, you're just seeing the country codes displayed as text in that column in the admin list view, correct?

[luke3141]

I'm seeing the country names in that column.

[SmileyChris]

Are you using the latest version?

[christianglodt]

I'm seeing the same problem here. I just upgraded from 2.0b4 to 2.1.2, and the problem persists.

I have an admin page with one CountryField in list_display and list_filter. According to DDT, with 100 rows, it takes about 3000 ms to load. Without the CountryField in list_display and list_filter, it takes about 120 ms.

I've profiled the page and attached a call-graph picture. The branch on the left shows something going on with the iter method (init.py:45) where I end up with a million calls to ugettext.

[SmileyChris]

Thanks for the profiling work, Christian.

It definitely seems that we need to cache the sorted country list against the language used in the current thread, so all future iterations have it presorted. This would tie in nicely with the work being discussed in #44

[vdboor]

It definitely seems that we need to cache the sorted country list against the language used in the current thread, so all future iterations have it presorted. This would tie in nicely with the work being discussed in #44

It seems to be that both can be done separately, implementing the caching. There is low hanging fruit in the code too, for example Countries.name(..) performs dict(self.countries).get(code, '') every time; the list of tuples is converted to a dict to be thrown away a millisecond later. That kind of thing would also improve the performance.

[SmileyChris]

Optimization has been done, this shouldn't be an issue now.

[ronny-rentner]

It's 10 years later and I have unfortunately the same problem. Showing a country column in admin makes it 10 times slower than without, so an admin change list view takes 700 ms CPU time instead of 70 ms according to django-debug-toolbar.

I am using django-countries version 7.6.1.