Ok, thanks all, So following Bill's advice, i did: >python manage.py shell >>> import game.models >>> list(game.models.Location.objects.filter( \ ... x__gte=34, \ ... x__lte=46, \ ... y__gte=24, \ ... y__lte=36))
...and the result showed up instantly! So it seems DB is not the issue. Will do other testing... On Nov 1, 4:18 pm, Bill Freeman <ke1g...@gmail.com> wrote: > My experience with Django debug toolbar is that it makes things > slow all by itself. > > I have done a couple of apps that use the equivalent query, using PostgreSQL, > without noticing a performance issue, with everything running on a Linux > server. > > 1. Have you tried timing the query by hand? That is, run the manage.py shell, > import your model, and type a sample version of the query, wrapped in a list() > operation to force the query to evaluate right away. If it's slow, > then you problem > is at least mostly in your DB/query choice. > > 2. Is the machine in question tight on memory? That could make things slower > that it would be on a production instance. > > 3. You might look at the "range" field lookup instead of pairs of > gte, lte. I doubt > that it makes a performance difference, and I don't know if SQLite supports > BETWEEN, but it's easy to try. > > 4. You show x and y as integers, but if that was just by way of example, and > they are really some complex (non-scalar) data type, the comparisons may not > be cheap on the database. > > Bill > > On Mon, Nov 1, 2010 at 8:13 AM, Javier Guerra Giraldez > > <jav...@guerrag.com> wrote: > > On Mon, Nov 1, 2010 at 5:55 AM, Cal Leeming [Simplicity Media Ltd] > > <cal.leem...@simplicitymedialtd.co.uk> wrote: > >> 9 out of 10 times, the bottleneck is usually the database > > > true, but 8.7 of those 9 are about how the database is used, and not > > about the engine choice. simply changing SQLite won't improve > > significantly the one-user case. > > > the trick is: 1) get as few db queries as possible for each page. 2) > > use appropriate indices for those queries > > > but first of all, you have to identify if it is really the DB where > > you're spending time. the easiest way to be sure is to install > > django_debug_toolbar app, it's great to tell you exactly what's going > > on with the time and the DB accesses. > > > -- > > Javier > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
