Re: ORM performance

On 04/09/14 Benjamin Scherrey said: > The short answer to your question is no, the Django ORM is not inherently > slower in that regard and it's very likely something you're doing. The Given that it's basically for obj in foo.objects.all(): obj.prop = new_value obj.save() I fail to see

Re: ORM performance

On 03/09/14 Tom Lockhart said: > I haven't had to deal with this myself, but the speed difference smacks of > transactional issues. If you can run your loop by wrapping all of it or > pieces of it (say, 100 or 1000 chunks) in a single transaction you'll > probably see some significant speedup.

Re: ORM performance

On 04/09/14 Tom Evans said: > Is the update invariant? By using the ORM like this: As I said, each update is unique and they cannot be batched. > Are both Django and the sqlalchemy doing the same sort of update? Yes. Identical. Mike -- You received this message because you are subscribed to

Re: ORM performance

On Thu, Sep 4, 2014 at 12:22 AM, msoulier wrote: > Hi, > > I am looking at Django's performance with respect to modifying large numbers > of objects, each in a unique way that cannot be batched. If I make a simple > change to one of my Django models and save(), and then

Re: ORM performance

Thanks to the OP for asking this, and to all who answered. Ben, special stars to you - you just shared some very valuable insight into efficieint use of the ORM (wasn't obvious to me). Kind regards, Lloyd On Thu, Sep 4, 2014 at 2:21 AM, Benjamin Scherrey wrote: > The

Re: ORM performance

The short answer to your question is no, the Django ORM is not inherently slower in that regard and it's very likely something you're doing. The useful answer is probably more complicated. :-) Naive usage of the ORM without an understanding of how it translates to SQL is likely to result in some

Re: ORM performance

On 2014-09-03, at 4:22 PM, msoulier wrote: > Hi, > > I am looking at Django's performance with respect to modifying large numbers > of objects, each in a unique way that cannot be batched. If I make a simple > change to one of my Django models and save(), and then

ORM performance

Hi, I am looking at Django's performance with respect to modifying large numbers of objects, each in a unique way that cannot be batched. If I make a simple change to one of my Django models and save(), and then do the same thing in sqlalchemy, I notice a performance difference of about 48

Django ORM performance patch. Fixes #5420, #5768

I made a patch for Django to add QuerySet.fields(*fields, **related_fields) and make possible to load only some from master and related models fields. It allows to tune various object list queries when we need only limited subset of all fields, improve general performance and decrease database

Re: ORM / Performance

yezooz napisał(a): >>> two words: intelligent caching >>> Know what you're asking for commonly, and cache it up with memcache. >>> That will do you a world of benefit. >> Well of course caching will solve some of the problems, but cache >> still needs to regenerated sometime... > > I should say

Re: ORM / Performance

On 9/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I have an app (0.96 so no select_related) that had a large initial To be clear, select_related has existed for quite a while in Django -- 0.91 at least. > I got a lot of mileage by caching just in a dictionary > the foreign keys so

Re: ORM / Performance

I have an app (0.96 so no select_related) that had a large initial data load consisting of a couple core tables and several foreign key relationships. I got a lot of mileage by caching just in a dictionary the foreign keys so that the ORM wasn't doing lots of redundant queries. I found the same

Re: ORM / Performance

> Between caching, profiling, and having a good sense of what your Profiling...the #1 thing to do. Without profiling the app under "normal usage" (common actions & browsing patterns gleaned from the current deployment) scaled to high loads, you're just twiddling knobs and wasting time. If

Re: ORM / Performance

On Sep 18, 11:06 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I want to say one word to you. Just one word. > > http://en.wikipedia.org/wiki/Denormalization That's the word I'm familiar with :) I'm using it, but not as often as I probably should. So in your opinion Djano's ORM is good

Re: ORM / Performance

I want to say one word to you. Just one word. http://en.wikipedia.org/wiki/Denormalization On Sep 18, 10:57 pm, yezooz <[EMAIL PROTECTED]> wrote: > On Sep 18, 10:34 pm, "Joseph Heck" <[EMAIL PROTECTED]> wrote: > > > Without knowing a hell of a lot more of the details of you site, what > >

Re: ORM / Performance

On Sep 18, 10:34 pm, "Joseph Heck" <[EMAIL PROTECTED]> wrote: > Without knowing a hell of a lot more of the details of you site, what > you're trying to do, etc - nobody can reasonably answer this question. > The ORM is fine, but if it's not as fast as you need for certain > queries, you can

Re: ORM / Performance

Without knowing a hell of a lot more of the details of you site, what you're trying to do, etc - nobody can reasonably answer this question. The ORM is fine, but if it's not as fast as you need for certain queries, you can always drop back to RAW sql to see if that will give you speed. At the

Re: ORM / Performance

On Sep 18, 10:23 pm, yezooz <[EMAIL PROTECTED]> wrote: > On Sep 18, 10:14 pm, "Joseph Heck" <[EMAIL PROTECTED]> wrote: > > > two words: intelligent caching > > > Know what you're asking for commonly, and cache it up with memcache. > > That will do you a world of benefit. > > Well of course

Re: ORM / Performance

On Sep 18, 10:14 pm, "Joseph Heck" <[EMAIL PROTECTED]> wrote: > two words: intelligent caching > > Know what you're asking for commonly, and cache it up with memcache. > That will do you a world of benefit. Well of course caching will solve some of the problems, but cache still needs to

Re: ORM / Performance

two words: intelligent caching Know what you're asking for commonly, and cache it up with memcache. That will do you a world of benefit. -joe On 9/18/07, yezooz <[EMAIL PROTECTED]> wrote: > > hi all, > > I'm sure many of you run high traffic websites in Django and I'm very > curious how you're

ORM / Performance

hi all, I'm sure many of you run high traffic websites in Django and I'm very curious how you're avoiding performance hit caused by built-in ORM. Select_related not always working and it's still might generate dozens of select's. Are you just running custom SQL queries with joins ? greetings