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
24251	TransactionTestCases run incredibly slowly since 1.7.4	Steve Jalim	nobody	"Hi

On a project with a reasonable number of tests (~1600) the overall performance of our test suite under Django 1.7.3 averages around 1 second per test (27 mins total - not amazing, but tolerable)

On 1.7.4, the identical codbase takes (literally) several hours to run.

Something was clearly up, which I briefly discussed with @timograham on #django-dev. 

Git bisect on the 1.7.x/stable branch reveals the issue to be caused by commit 478546fcef38d95866a92bc44d10e15b26c7254c 

(My read of that commit and related ticket is that a short-term patch was put in to fix an edge case with migrating contenttypes, but I'm happy to be corrected. That patch will have to stick around until 1.9, not 1.8 it seems)

Digging a little deeper, I put in some naive print-based logging to see how often `is_latest_migration_applied` and `loader.load_disk()` are called.

(For context: our codebase has 50 1.7-era migrations, across 23 apps)

For TestCases, neither of the above is called between tests - they are only called during test DB bootstrap (multiple times, in line with the existence of multiple migrations). 

However, for TransactionTestCases, between each and every test `is_latest_migration_applied` is called around 100 times, each calling `loader.load_disk` twice.

We have a relatively high proportion of TransactionTestCases (roughly 75%+), but am pretty sure we can't be alone in experiencing this - it looks like something that will affect every codebase with TransactionTestCases.

This is all against Postgres9.3, but  very similar behaviour (with different timings) is apparent when running against in-memory sqlite -- ruling out DB bottlenecks as the sole/key cause.

I'm not close enough to the migrations framework to have a decent picture of things, but my key thought is: loader.load_disk() seems to be taking all the resource, because its' called so often. Does it have to be called quite so frequently?

Cheers folks - happy to add more detail as needed, but I cannot share the project (which I know is a PITA)

Steve"	Cleanup/optimization	closed	Uncategorized	1.7	Normal	fixed		Markus Holtermann	Accepted	0	0	0	0	0	0