我正在使用API，以便从我的项目中获得一些服务。 API调用花费的时间太长，因此我认为原因之一可能是我在整个项目中放置的很多日志，而IO读/写却花了一些时间。
我正在使用logging。我的猜测是，LOG_LEVEL丢弃优先级较低的日志，而优先级较高的API调用应在更短的时间内完成。但是时间几乎是相同的（差异在1/10秒的范围内）。
从here获得的关于LOG_LEVEL和性能的唯一参考是
这样做的好处是，如果将日志级别设置为WARN，则信息和调试消息几乎不会影响性能。
一些要注意的地方
我尚未将日志配置为流式传输到任何日志服务，例如Kibana。
我已经检查过this种情况，但没有在日志消息中做任何假设。
我已经完成了Logger的基本初始化，即
导入日志记录
logger = logging.getLogger（__ name __）
和未使用的任何文件将日志写入如下。 LOG_LEVEL作为环境变量之一给出。
logging.basicConfig（filename =“ file_name.log”）
考虑到其他所有事物都是最优的（如果所有事物都不都是最优的，那么优先级较高的日志应该花费更少的时间），由于日志读/写，我猜错了更多的时间吗？如果否，那么为什么使用高优先级LOG_LEVEL标志不会减少时间？
日志记录模块将日志存储在哪个默认位置？
答案 0 :(得分：2)
日志级别的性能有何区别？
设置日志级别可能会影响性能，但是直到大规模时才可能引起注意。
设置级别时，您正在创建一种阻止日志记录过程继续进行的方法，在用任何单个日志进行检查之前几乎没有发生任何事情。例如，以下是code中的CRITICAL日志：
if self.isEnabledFor(CRITICAL):
self._log(CRITICAL, msg, args, **kwargs)
作为_log的一部分，记录器本身要做的事情还不止此检查，因此通过设置日志级别可以节省时间。但是，它是相当优化的，因此在您启动记录器的那一点上，除非调用量之间的差异很大，否则您可能不会注意到它。
如果删除对日志记录的任何引用而不仅仅是设置级别，那么您将获得更多的性能提升，因为该检查根本没有进行（显然要花费一些时间）。
默认情况下日志存储在哪里？
默认情况下，未设置文件就启用StreamHandler [source]，并且不指定特定的流，它将流向sys.stderr。设置文件时，它会创建一个FileHandler，该文件继承自与StreamHandlers [source]相同的功能。
如何优化？
对于您没有问过的问题，这是如何加快记录速度？我建议您看一下this，其中提供了一些建议。该建议的一部分就是我上面指出的内容，但告诉您明确检查日志级别，甚至可以缓存该结果并检查缓存，这样可以进一步减少时间。
查看this answer，以获取更多有关优化日志记录的信息。
最后，如果要确定代码的速度问题，无论是从日志记录还是从日志记录，都需要使用探查器。在Python中有内置的分析功能，请检查here。
答案 1 :(得分：0)
一个日志级别的性能不比另一个日志级别高，但是，如果启用了一个日志级别，则会嵌套日志记录器（在您的示例中，如果__name__中包含{{1} }），并且您正在运行的Python版本也可以。这是因为在进行记录调用时会发生三件事：
记录器确定是否启用了记录级别。
每次通话都会发生这种情况。在3.7之前的Python版本中，未缓存此调用，并且嵌套记录器需要更长的时间来确定是否启用了它们。要多久在某些基准测试中，时间是原来的两倍。也就是说，这在很大程度上取决于日志嵌套，即使记录数百万条消息，也可能只节省几秒钟的系统时间。
记录器处理记录。
这是in the documentation概述的优化起作用的地方。它们允许记录创建跳过一些步骤。
记录器将记录发送给处理程序。
这可能是默认的StreamHandler，FileHandler，SysLogHandler或任意数量的内置或自定义处理程序。在您的示例中，您正在使用FileHandler写入当前目录中的mypackage.core.logs。这对于较小的应用程序可能很好，较大的应用程序将受益于使用外部记录器（例如syslog或systemd日志）。造成这种情况的主要原因是因为它们在单独的进程中运行，并且针对处理大量日志进行了优化。