Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#11449 closed Cleanup/optimization (wontfix)

Performance regression loading from fixtures in 1.1 & trunk

Reported by: novalis Owned by: nobody
Component: Core (Serialization) Version: 1.1-beta
Severity: Normal Keywords: perf
Cc: em@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I have created a test that does nothing but read in a fixture. It goes significantly slower on Django 1.1-beta and trunk than it does in Django 1.0.

1.0: Ran 1 test in 4.940s
1.1: Ran 1 test in 21.541s
trunk: Ran 1 test in 21.228s

My rejected patch in #11181 reduces cuts each of these times in half -- but does not fix the regression.

Attachments (1)

perf.zip (223.9 KB) - added by russellm 6 years ago.
Test case that apparently demonstrates the problem.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 6 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I have to say this conflicts with my personal experience - I have found that tests under v1.1 run much faster than v1.0 tests, as a result of the transactional test case changes.

Would you care to share your exact test code?

comment:2 Changed 6 years ago by Alex

  • Resolution set to worksforme
  • Status changed from new to closed

It's been a month with no new information, closing as worksforme.

comment:3 Changed 6 years ago by russellm

  • Resolution worksforme deleted
  • Status changed from closed to reopened

@alex - There was a discussion on Django-users; the reporter just didn't update this ticket with the helpful details. I'll upload his test case.

Changed 6 years ago by russellm

Test case that apparently demonstrates the problem.

comment:4 Changed 6 years ago by russellm

  • milestone set to 1.2
  • Triage Stage changed from Unreviewed to Accepted

Provided test case is about 50% slower under 1.1 than under 1.0 in my tests; 1.2-alpha is slightly faster than 1.1, but not faster than 1.0. Worth some investigation.

comment:5 Changed 6 years ago by anonymous

  • Component changed from Uncategorized to Serialization

comment:6 Changed 5 years ago by jacob

  • Keywords perf added
  • milestone changed from 1.2 to 1.3

With 1.2 in the final stages and no more information about why this is slow, I'm booting it out of the milestone. Fixture loading isn't critical in deployment, so this shouldn't block the release.

comment:7 Changed 5 years ago by EmilStenstrom

  • Cc em@… added

In a big live project, our fixture loading is also slow... But for some reason, setting DEBUG to true at the top of our tests.py makes them fast again:

from django.conf import settings
settings.DEBUG = True

Or maybe this is some side effect of how we load our test_settting.py file when testing:

#!/usr/bin/env python
import sys
from django.core.management import execute_manager

try:
    if len(sys.argv) > 1 and sys.argv[1] == 'test':
        import test_settings as settings
    else:
        import settings
except ImportError:    
    sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
    sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

I'm not sure, but I thought I'd throw it out there as an idea of where to start looking.

comment:8 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to Cleanup/optimization

comment:9 Changed 4 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

comment:11 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:12 Changed 4 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:13 Changed 3 years ago by claudep

  • Resolution set to wontfix
  • Status changed from reopened to closed

Here are the benchmark results on my machine:

1.0 16s
1.1 23.7s
1.2 20.5s
1.3 19.5s
1.4 22.2s
dev 23s

I tried to profile the execution and saw that the slowdown was in the object save/save_base method. This is not related to serialization, but simply that saving objects is slower now than in the 1.0 days.

comment:14 Changed 3 years ago by akaariai

FWIW I think there is not much room for improvement in save_base itself, but there is plenty to improve in qs.clone() and generating the SQL string. Could you try the test with #16759 applied? I would guess you get around 20s execution time with that.

Note: See TracTickets for help on using tickets.
Back to Top