On 16 oct, 12:11, David Reynolds <[EMAIL PROTECTED]> wrote: > On 15 Oct 2008, at 3:27 pm, bruno desthuilliers wrote: > > > I could be (and I strongly suspect it would be), but I really can't > > tell for sure. Now this should be easy to find out, isn't it ?-) > > The csv module gave a slight speed increase (enough for me to notice > without any profiling or accurate timing
Doesn't really surprise me. > > There are also a couple micro-optimization tricks, like correct use of > > select_related, aliasing of frequently accessed attributes and methods > > outside a loop, etc, - so we could eventually help a bit if you post > > your code - but anyway : unless you do something very obviously wrong > > in your view, trying to optimize without first profiling is usually > > (from experience) a waste of time. > > > You could at least benchmark the view code *without* the template > > rendering to find out weither the main bottleneck is in the view code > > itself or in the template. > > I think I can see the problem... > > I have the following: > > class Contact(models.Model): > # Basic contact details > > class AddressBook(models.Model): > contact = models.ForeignKey(Contact) > # Various address fields > > class ContactMembership(models.Model): > customer = models.ForeignKey(Contact) > # Membership specific details > > The csv generator is being fed a list of ContactMembership objects, > it is then looking up the Contact details and AddressBook details. > > I can reduce queries slightly by using select_related(), but this > doesn't pull in the AddressBook model details, > so a query is run for > each row as it is added to the csv output to get the Address details. Given your models definitions, a Contact has one *or more* AddressBooks. Is this the right modeling for your app ? If so, which AddressBook instance do you use for your csv ? > Is there anyway I can optimise this with the ORM or am I looking at > writing some custom SQL or denormalising the data? If the above model definition is really the right one for your app, then my best bet would be to go for raw sql. Not only will it save you the one-extra-query-per-row, but also avoid the ORM overhead. FWIW, this will probably be better (performance-wise) than denormalizing *and* keeping the ORM !-). And while we're at it, if you go the raw SQL route, avoid the infamous 'select * ' when you only need a couple fields - this often really helps the RDBMS optimiser. using raw SQL, you should probably be able to exactly (or quite close to) match your rows with your CSV lines. And, last point, learn to make proper use of your DB index. Which doesn't mean "index all and everything", quite on the contrary - if an index is not selective enough (ie : if you get more than 20% of your table for a given index), then it may actually make things slower than a plain sequential scan (unless eventually this index is used for a join... Well, this starts getting complicated and sslightly OT - you may want to seek more help on the topic on a more appropriate neswgroup anyway...) HTH --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
