> unfortunately the logging module included with Python adds significant > performance overhead even if no handlers are configured. We would like > to be able to have fine-grained logging available in our library, but at > the same time when the logging is disabled for significant latency to not > be added to the application. Take a look at the source of logging.debug() > - a logger with a few levels of hierarchy and no handlers configured will > have about three method calls of overhead. Multiply that by, for > example, a log statement for each row received by RowProxy, and a log > statement for each column/result processor in the ORM, and it adds up to > many dozens of method calls per row. The primary hindrance to speed in > Python is function calls - perhaps projects like Unladen Swallow will > improve this but for now, Python application profiling is almost a linear > function w.r.t number of method calls. So we can either remove all the > log.debug() statements we have and just not have the capability available, > or gate them within a conditional as we've done.
Thanks, it is now clear for me. > Though have > you tried DEBUG level sqlalchemy.engine ? the result set processing > necessarily needs to be implemented as distinct log lines, so you'd still > have the problem of associating many log lines with one record. there's > a connection proxy that can be used for more elaborate schemes. For my needs debug messages is not so interesting as informational. But maybe it is possible to add some unique identifier for each log record params? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
