Reporting back on some additional findings for what it's worth. SmileyChris dumped and recreated the project in question's migrations, manually ordering them to minimize dependencies. It was not a major reduction in total migrations: 82 to 58 (mostly third-party migrations and initials), but the time to create an empty migration dropped massively. It went from 260s on 1.8.6 (160s on 1.9.1) to 2s on both versions.
I'm not sure what to make of it, but the slowness I was seeing doesn't seem to be as much related to number of migrations, but perhaps the contents of the migrations files. Is it possible that having lots of cross-app migration dependencies could be the cause? Thanks as always! -- Pete On Thu, Jan 7, 2016 at 3:12 PM, Carl Meyer <[email protected]> wrote: > On 01/07/2016 03:03 PM, Aymeric Augustin wrote: >> As far as I understand, the CPU cost comes from generating a full set of >> model classes for each step of the migration history. That’s consistent >> with the profile sent by Florian. >> >> I usually end up throwing away the migration history and regenerating a >> new set of migrations when I get to that point. This requires truncating >> the django_migrations table manually and faking the new set of migrations. >> >> If the project doesn’t use data migrations, squashmigrations may achieve >> the same effect. Sadly real-life projects tend to have data migrations >> whose only purpose is to run once in production. They prevent full >> squashing. > > FWIW, I've also done a hybrid of these two options, where I generate > fresh initial migrations rather than actually using squashmigrations > (for the same reason, to avoid problems with data migrations), but then > I still keep the old migrations around for a transition period and use > the `replaces` attribute (the same one added automatically by > `squashmigrations`) on the new initial migrations. Then later (once the > new migrations are deployed everywhere) delete the old migrations and > the `replaces` attr. > > Effectively this is similar to what you're doing, it just takes > advantage of the `replaces` feature to avoid manually fiddling with the > migrations table on each deployment. > > If I (or anyone else) ever gets around to it, I think > https://code.djangoproject.com/ticket/24109 could make the actual > squashmigrations command usable for real projects, by letting you just > mark certain migrations as "please ignore when squashing". > > Carl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/568EE2B2.1040501%40oddbird.net. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAAoxf4sacLi4faHx0qXuP3WF8ZXT-4nU9qcub_QGDBaHJ_em%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
