id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 24743 Django 1.8.1 migrations are actually slower than 1.8? Peter Schmidt Markus Holtermann "Ran `time ./manage.py test .`, results: 1m25.611s https://github.com/django/django/commit/2329ca969f81309bd3d15da55f25f8e1bee3122d 1m26.505s https://github.com/django/django/commit/0cacb8f8ba94b06a78dcdfa22dc406a8a20a7f88 0m36.864s https://github.com/django/django/commit/697317f3340b1d1f40586262098ad4dbae9aebaf 0m36.250s https://github.com/django/django/commit/516907540b81c009b74d29b2fa36319b47528b49 1m6.195s https://github.com/django/django/commit/43f800a978deba4bc8d13e7f11e0afdc126cec25 Some quick stats for our project - 134 models, 90 apps across 2 databases, 58 migrations in our django_migrations table (the bare minimum needed to get us through Django 1.7 and 1.8). Thought I'd put it out there and see if others are getting similar overall slower results. -- P.S. I don't really care either way what happens with ticket - take it, close it, whatever. I was just surprised that the migrations ran more slowly under 1.8.1 when the release notes suggested otherwise. https://docs.djangoproject.com/en/1.8/releases/1.8.1/#optimizations P.P.S. In practice migrations take sufficiently long relative to Django 1.6 that I've ended up building a `--ramdb` option into https://github.com/pzrq/discover-road-runner which is why I don't really care a great deal anymore - the second (and next dozen) times a 2s unit test is run it takes around 2s instead of around one minute (to rerun the migrations over again, I haven't checked if `--keepdb` has been updated since the 1.8 beta to work with in-memory SQLite databases)." Cleanup/optimization closed Migrations 1.8 Normal fixed Markus Holtermann marten.knbk@… chris@… M. Jackson Wilkinson Ready for checkin 1 0 0 0 0 0