> On Nov 12, 2014, at 4:46 AM, Ladislav Lenart <lenart...@volny.cz> wrote:
>
> Hello.
>
> I am in the process of eliminating bottlenecks in our application.
>
> I have measured relative speed of the following querying methods:
> limit = 10000
> q_orm = session.query(Foo).limit(limit)
> q_id = session.query(Foo.id).limit(limit) # primary key
> stmt = q_id.statement
> sql = "SELECT foo.id FROM foo LIMIT {}".format(limit)
>
> Execution:
> r = q_orm.all()
> r = q_id.all()
> r = session.execute(stmt).fetchall()
> r = session.execute(sql).fetchall()
>
> I have found the following relative speeds of the above methods:
> q_orm 1x (slowest, expected)
> q_id 13x (relatively slow, NOT expected)
> stmt 70x (fastest, expected)
> sql 70x (fastest, expected)
>
> I am curious about a relative slowness of the second method (q_id). What is it
> doing? I thought there should be NO ORM overhead given that the query does NOT
> return ORM instances.
there is overhead in the named tuple that is returned. this overhead is
improved in 1.0, see
http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html#new-keyedtuple-implementation-dramatically-faster
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
