On Jan 14, 11:07 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Thu, Jan 14, 2010 at 4:43 PM, Piotr Czachur <zim...@gmail.com> wrote: > > Guys, > > I was really unhappy to see how slow fixtures are loaded before every > > test. I'm not talking about initial_data stuff that is loaded just in > > beginning, and then reset by rollback. Fixtures used for unit tests > > are loaded on demand (fixtures = [f1, f2]), and this is really slow, > > because thousands of SQL queries going to database (SELECTs, SELECTs, > > INSERTs). > > For my small test suite (130 tests) and small fixtures (15 items) I've > > recorded ~16000 queries to database - I was really blown away by this > > number. 99% of this queries was related to fixtures loading. > > We are well aware of the speed problems associated with fixture setup > and teardown during testing. We're open to any practical suggestions > on how to speed them up. >
I came across some similar issues with an Event/Occurrence pair of models (each Event has one or more occurrences, representing the potentially repeating nature of the event). Because an Event could have many thousand Occurrences, and modifying the Event may require modifying, or even recreating all of the Occurrences, I looked at some ways to improve performance. Because we have a series of homogenous object types, we can combine all of the SQL queries into one. I wonder if something similar could be done with fixtures: create all of the objects, but instead of saving them one at a time, save them in one batch. I hand coded the query, as this was a development exercise, and wasn't for production. This would probably require significant thought as to the best way to do this: perhaps a create_many() method on the Manager might be a better solution? I think I'll have another look at this - I'm about to revisit that code anyway. Any other suggestions are welcome, too :) > > As I said, we're more than happy to look at any proposal to improve > the speed of testing in Django, but those changes can't come at the > cost of fundamentally changing what it means to write a test. Agreed. I use the different fixtures in test classes to have a known state at the beginning of each test, that varies across test cases. Matt.
-- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
