Malcolm Tredinnick a écrit :
> On Fri, 2008-02-15 at 16:37 +1100, Malcolm Tredinnick wrote:
> [...]
>
>> The change wasn't made solely because of the speed benefits. Models just
>> aren't created that often for it to be the most relevant factor (__new__
>> is only called import time normally).
On Fri, 2008-02-15 at 16:37 +1100, Malcolm Tredinnick wrote:
[...]
> The change wasn't made solely because of the speed benefits. Models just
> aren't created that often for it to be the most relevant factor (__new__
> is only called import time normally). It was also made because it makes
> the
> I understand this may be a corner case, but the ability to extend
> Django's initialization is really nice, and this optimization makes the
> code ugly on the applications side (and was there really a need for an
> optimization ? "1-1.5s per 1 models" does not tell much on what has
> been ga
On Fri, 2008-02-15 at 02:47 +0100, Luper Rouch wrote:
[...]
> CustomModel is not Model, but as it is not initialized by Django it does
> not have a _meta attribute either (and I don't want it initialized by
> Django because it would create a *_custommodel table, plus the extra
> unnecessary initi
I use custom metaclasses to do some additional initialization in my code :
class CustomMetaclass(ModelBase):
def __new__(cls, name, attrs, bases):
# Skip Django initialization if we are looking at CustomModel
try:
CustomModel
except NameError:
r
Updated the patch http://code.djangoproject.com/ticket/6214
Another small optimization.
1. It passes all unit tests
2. It is IMO more clear
3. It is faster (1-1.5 seconds per 1 models on my machine) than
current django model creation
--~--~-~--~~~---~--~~
You r
All tests passed. Very simple benchmarks show speed increase of about
0.04-0.07 seconds per 1000 model classes compared to hasattr() version
and about 0.15 seconds per 1000 model classes compared to dir(base). I
know it is not dramatically faster but it *is* faster (and IMHO
clearer and more DRY).
Please make sure these changes do not cause any unit test failures.
Also, benchmarks!!! :-) How much of a speed difference is there thanks
to these latest changes you've made to ModelBase? And you may want to
run benchmarks and ensure its not effecting speeds adversely
elsewhere.
On Dec 24, 1:08
I was able to optimize it even more by moving classmethods of Model to
ModelBase as normal methods. It's really faster and clearer because
separates initialization of Model classes and Model instances
On 24 дек, 23:41, "ivan.illarionov" <[EMAIL PROTECTED]> wrote:
> My patch is little faster again
My patch is little faster against hasattr() 2.54 vs 2.56 and 2.56 vs
2.59
On 24 дек, 22:04, "ivan.illarionov" <[EMAIL PROTECTED]> wrote:
> Just benchmarked my patch. Class creation runs faster. 1000 simple
> classes was created in 2.5 seconds vs. 2.7 seconds and 1000 subclasses
> in 2.6 vs. 2.8
>
Just benchmarked my patch. Class creation runs faster. 1000 simple
classes was created in 2.5 seconds vs. 2.7 seconds and 1000 subclasses
in 2.6 vs. 2.8
On 24 дек, 20:59, "ivan.illarionov" <[EMAIL PROTECTED]> wrote:
> Please take a look at my patch athttp://code.djangoproject.com/ticket/6214
> Th
Please take a look at my patch at http://code.djangoproject.com/ticket/6214
There's no need to check for _meta
if base is not Model and issubclass(base, Model)
All Model subclasses except Model class itself have _meta attribute.
It can be optimized further if we build the list of parents in the
On Mon, 2007-12-24 at 00:37 -0800, David Cramer wrote:
> Any reason it's not the default?
It might not always be available, was one concern (although I suspect
not a real problem). The other one is that if you're running your
application's tests, you should be using the same encoding that your
p
Any reason it's not the default?
On Dec 24, 12:31 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2007-12-23 at 23:47 -0800, David Cramer wrote:
> > With the latest trunk I actually had 4 unit test failures -- maybe my
> > setup is screwed.http://www.pastethat.com/VulU5
>
> > These ha
On Sun, 2007-12-23 at 23:47 -0800, David Cramer wrote:
> With the latest trunk I actually had 4 unit test failures -- maybe my
> setup is screwed. http://www.pastethat.com/VulU5
>
> These happened either way though, the same errors.
Looks like you might need to set TEST_DATABASE_CHARSET='utf-8'
David Cramer wrote:
> With the latest trunk I actually had 4 unit test failures -- maybe my
> setup is screwed. http://www.pastethat.com/VulU5
>
> These happened either way though, the same errors.
David, looks like your test DB is not created in utf-8 charset. Try
these two settings:
http://w
With the latest trunk I actually had 4 unit test failures -- maybe my
setup is screwed. http://www.pastethat.com/VulU5
These happened either way though, the same errors.
On Dec 23, 9:03 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Dec 23, 2007 8:02 PM, David Cramer <[EMAIL PROTECTED]> w
On Dec 23, 2007 8:02 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I was looking over some code today and noticed that the __new__
> definition of ModelBase does if x in dir(y). Doing some quick tests
> showed this was a lot slower than doing if hasattr(x, y). Is there any
> reason it's done like
I was looking over some code today and noticed that the __new__
definition of ModelBase does if x in dir(y). Doing some quick tests
showed this was a lot slower than doing if hasattr(x, y). Is there any
reason it's done like this?
http://www.pastethat.com/Qxayj
This is the specific group of line
19 matches
Mail list logo
