""" Now for the funny part of this. I suspected that __setattr__ would make init slower. But using a little trick, __init__ is now actually almost 30% faster for a 10 field model. The trick is checking if setattr needs to be called. It needs to be called if the user has defined __setattr__ for some subclass of Model, otherwise we can call directly object.__setattr__. For some reason, this is considerably faster than calling setattr(self, f.attname, val). I hope the approach is acceptable. The same trick could be employed directly to trunk version of Django, resulting in the same speedup. """
Now I can't reproduce this speedup. I get pretty much the same speed on master vs the __setattr__ trick. I don't know what I was doing wrong before, I tested this literally tens of times trying to understand what is happening. It is not that surprising that this speedup isn't real, as the speedup seemed too good to be true. So, forget about the above optimization for current Django trunk. However it is still needed if the __setattr__ way of tracking attribute changes is going to be used, as otherwise model __init__ will be much slower than currently. I do understand if this is not wanted, as this adds some complexity and if the only benefit is preventing accidental duplicates due to PK change, it is questionable if it is worth it. However saving only changed attrs (and skipping the save completely if there are no changes) could be nice in some situations. Maybe I should sleep a little before hacking more... :) Anyways it is probably good to let this all wait until 1.5. There are pretty big design decisions here. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
