Christian Démolis wrote:
> i made a test
> i did that without sql alchemy orm:
>
> import MySQLdb
> import time
> # Establich a connection
>
> db = MySQLdb.connection(host="192.168.45.28",
> user="apm",
> passwd="apm",
> db="test_christian")
>
> # Run a MySQL query from Python and get the result set
> xref = time.time()
> db.query("""UPDATE utilisateur SET Dispo=1 WHERE IdUtilisateur=1""")
> r = db.store_result()
>
> print time.time()-xref
> # Iterate through the result set
> # Example calls back up to 100 rows
>
> # for row in r.fetch_row(100):
> # print row
>
> *EXECUTE*
>
> Z:\>python TestSql.py
> 0.108999967575
>
> It takes 0.1 s (the database is far away from the code)
>
> ------------------------------------------------------------------------------
> And then i test this (just a part of my application)
>
>
> def SeRendreIndisponible(self,event): # FONCTION COSMOCOM
> xref = time.time()
> if self.app.connec["CouplageCosmocom"]==0 : return
> if hasattr(self, 'agent') :
> try :
> self.agent.MakeReleased()
> except :
> self.app.ReconnexionAgent()
> self.agent.MakeReleased()
> print "SeRendreIndisponible PARTIE AGENT", time.time()-xref
> xref = time.time()
> self.UtilisateurCourant.Dispo = 0
> if self.UtilisateurCourant.IdUtilisateur:
> x = self.ModifBase(self.UtilisateurCourant) # on réactualise
> l'état de la bdd
> print "====>>>", x
> print "SeRendreIndisponible PARTIE ECRITURE ETAT",
> time.time()-xref
>
> def ModifBase(self, objet):
> if int(self.app.param["Debug"]) :
> print "M", objet
> # try:
> x = session.merge(objet)
> session.flush()
>
> *EXECUTE*
>
> SeRendreIndisponible PARTIE AGENT 0.0
> M <Declaration.Utilisateur object at 0x032C0DD0>
> ====>>> None
> SeRendreIndisponible PARTIE ECRITURE ETAT 0.93700003624
>
>
>
>
> It takes 0.9 seconds with SqlAlchemy (>>0.1)
using the profile module will grant some perspective over what is going on.
For one thing, I can see at least four method or function calls in your
ORM example that aren't in the DBAPI version. For example, what does
MakeReleased() do ? Additionally, there's a try/except there. If an
exception is actually thrown, that alone could cause 50% of the time
overhead since exception throws are slow.
As far as the ORM itself, an ORM using unit of work doesn't know what kind
of UPDATE statement or statements should be generated ahead of time so
needs to perform many additional steps (fast steps, but more nonetheless)
in order to determine what needs to happen. Again the profile module
will illustrate this. You also should be on the latest 0.5 release of
SQLA as there were some bottlenecks that were fixed earlier in the 0.5
series.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
