[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-29 Thread Michael Bayer
the method that I improved in my checkin is related to the mapper's construction of a newly loaded instance, and the test case that improves 20% focuses most of its time loading a list of 2500 items. the test you have here spends a lot of time doing lots of other things, such as saving items

[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-28 Thread david mugnai
Michael Bayer wrote: [snip] actually a lot better than they've been in the past. if your tests are useful, I might add them as well (but note that your attachments didnt come through, so try again). I forgot the attachments, sorry. Please find them here:

[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-28 Thread Sébastien LELONG
one thing that could make ORM loads much faster would be if you knew the objects would not need to be flushed() at a later point, and you disabled history tracking on those instances.  this would prevent the need to create a copy of the object's attributes at load time. This reminds me a

[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-28 Thread Michael Bayer
if its truly an issue of security then grants would be more appropriate. since anything the ORM does to prevent a write operation can be easily overridden, since its Python. simpliest thing would be to use a Session that has flush() overidden. or an engine that overrides execute() to check for

[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-28 Thread Sébastien LELONG
[...] simpliest thing would be to use a Session that has flush() overidden. or an engine that overrides execute() to check for INSERT/UPDATE/DELETE statements and throws an error [...] I tried the ReadOnlySession class which overrides the flush() func. Works like a charm, this adds a

[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-27 Thread Michael Bayer
the ORM is going to be slower in all cases since there is the overhead of creating new object instances and populating them, as well as initializing their attribute instrumentation and also a copy of their attributes for the purposes of tracking changes when you issue a flush() statement. this

[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-27 Thread Lele Gaifax
Michael Bayer wrote: the ORM is going to be slower in all cases since there is the overhead of creating new object instances and populating them, as well as initializing their attribute instrumentation and also a copy of their attributes for the purposes of tracking changes when you issue a

[sqlalchemy] Re: Performance of data mapping and plain access

2006-12-27 Thread Michael Bayer
ive committed in r2174 some speed enhancements, not including the abovementioned change to deferring the on-load copy operation (which is a more involved change), that affords a 20% speed improvement in straight instance loads and a 25% speed improvement in instances loaded via eager