Again, it's hard to tell what the slowdown might be caused by without a
more detailed
investigation. I suggest you use cProfile[0] for that.
Given your tests are only running for a small amount of time relative to
Django's setup
time I assume two things are causing the apparent slowdown:
1. A s
Ah, but the slowdown is happening from 1.8 forward, each version of Django
make things just a bit slower. It's a gradual slowdown.
I do think I've got 3.2x libsqlite though. So we can account for the
slowdown on 2.1 -> 2.2
/usr/lib/libsqlite3.0.dylib
/usr/lib/libsqlite3.dylib
/usr/local/Cellar/
I meant Django 2.0 -> 2.1. As long as you are using Django 2.2 with SQLite
3.20+
the slowdown I mentioned should be effective.
Simon
Le samedi 15 juin 2019 08:32:56 UTC-4, Mark Jones a écrit :
>
> Maybe that's the case, I didn't build the python2.7 or 3.7, but I used
> pyenv to install 3.4, 3.5
Maybe that's the case, I didn't build the python2.7 or 3.7, but I used
pyenv to install 3.4, 3.5, and 3.6 and they are all using the same version
of SQLite. And with each version of python, the tests slow down as the
version of django increases. Could this still be the SQLite v2.1->v2.2?
Django
Hi Mark,
It's hard to tell exactly what's going on without more details but assuming
you are running tests
against SQLite the 2.1 to 2.2 slowdown is likely caused by the fact
database constraints are
now checked of each TestCase[0].
Cheers,
Simon
[0] https://docs.djangoproject.com/en/2.2/relea
I was fixing up a Django app https://github.com/mark0978/django-softdelete and
setting up tox to make sure it worked with all the listed versions because
of issues opened on the original repo. While I was running tox locally I
noticed that with every version of Django, the tests ran slower, and
6 matches
Mail list logo
