Wow – I’m really glad I learned about this performance hit on the Django list today.

Turns out that in the process of attempting to give back from really nice error messages from the default AddManipulator’s in Django 0.95, it has a HUGE performance impact that is documented, but man – I would’a easily missed it. The default value for “raw_id_admin” on a ForeignKey model in Django is False. Turns out the implications of that are that when you invoke an AddManipulator for an object with a ForeignKey relationship somewhere, it attempts to load up all potential values into memory and check against them… Yuck!

I really couldn’t believe this, so I went home and using the models from that mail thread, I created a test app and ran some time. Here’s what I got:

Yeah – that’s something like near linear growth of the time it takes to add a new object with the number of potential relationships.

Update: I posted the test case I created as bug #2638

In the 0.95 release code, the model valdiation logic can be a little shakey. In particular, I ran into this traceback today while doing a little code conversion:

<code>
Traceback (most recent call last):
  File "manage.py", line 11, in ?
    execute_manager(settings)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/core/management.py",
line 1319, in execute_manager
    execute_from_command_line(action_mapping, argv)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/core/management.py",
line 1243, in execute_from_command_line
    action_mapping[action]()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/core/management.py",
line 1003, in validate
    num_errors = get_validation_errors(outfile)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/core/management.py",
line 933, in get_validation_errors
    if not hasattr(cls, fn):
TypeError: hasattr(): attribute name must be string
</code>

Turns out this code is much happier in the trunk version than the 0.95 release, but the error ultimately means that I messed up and what was returned in an Admin list_display entry wasn’t a list or tuple, but something else.

In particular, this model code:

<code>
class Category(models.Model):
    cat_type = models.CharField(maxlength=25)
    def __str__(self):
        return self.cat_type
    class Admin:
        list_display=('cat_type',),
</code>

threw the error – it was that nasty little comma at the end of list_display…