Jon Nelson wrote:
> I assume that the purpose of this is to save performance?
correct.
> I note that the way much of the logging (esp. in pool.py) seems to be
> written is like this:
>
> somelogger.log("String ..." % (var1,var2,var3))
> and of course, regardless of the loglevel specified this always
> interpolates the variables - a fairly significant performance penalty
> for sure.
well no, because all the log statements are underneath conditionals and
are not evaluated otherwise.
>
> Shouldn't the style be:
>
> somelogger("String ...", var1,var2,var3)
>
> which prevents interpolation unless the loglevel is actually
> sufficient?
yes, it should. patches are welcome, but again not a big deal.
Would that not obviate the need for _should_log_info (and
> _should_log_debug) ??
unlikely. The conditionals save an enormous number of method calls into
the logging package in any case. Python seems to incur an inordinate
amount of overhead for method calls.
> I'm willing to supply a patch that changes the format of the calls to
> the logging system if that's useful.
sure ! if you are curious, try running the tests test_zoomark and
test_zoomark_orm to see the method call overhead added by even null
logging.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
