[ADVICE] log改为异步执行？

[Zeyi-Lin]

🤪 Features description [Please make everyone to understand it]

有用户群里反馈，在指标数大于600时，在服务器上执行首个step的log要30s，之后每个step的log要3s，非常影响训练时间；而使用wandb没有这个问题，所以可能需要考虑log使用异步执行，或找到性能瓶颈在哪里。

测试代码：

import swanlab
import time
import jax

swanlab.init(project="dev", mode="local")

data = {f'key_abcdefghijklmnopqrst_{i}': jax.numpy.array(i * 1.5) for i in range(600)}
print(data)

total_start = time.time()
for i in range(100):
    epoch_start = time.time()
    swanlab.log(data)
    epoch_end = time.time()
    print(f"Epoch {i+1}/100 took {epoch_end - epoch_start:.2f} seconds")

total_end = time.time()
print(f"Total time taken: {total_end - total_start:.2f} seconds")

👍 What problem does this feature solve

降低swanlab.log带来的训练时间影响

[SAKURA-CAT]

改为异步的方案有两种：

1. 新增一个线程或者定时任务，在当前进程内运行
2. 新增一个进程，将用户的log传给新进程，即 [REFACTOR] 整体性重构  #769

方案1定时任务在GIL锁的影响下无法做到计算密集型程序的性能提升，方案2的工程量会有些大。目前来看，核心在于检测运行缓慢的原因是什么，可能是在IO上（写入数据库、写入本地文件）。

我将在解决 #780 的过程中深入研究此问题

[SAKURA-CAT]

测试设置场景为一次上传1k个标量指标，核心代码如下，其中time_recorder 是一个临时的装饰器，用于统计函数执行时间：

@time_recorder
def many_metrics(ep):
    swanlab.log({str(n):n for n in range(1000)}, step=ep)

---

首先比较云端、本地版本之间的耗时差异，判断是否为云端上传线程影响了时间。

1. 云端模式的运行时间：

2. 本地模式的运行时间：

可以看到云端版本和本地版本之间差异不大，那么基本可以认定为IO的影响，接下来在local模式下进一步测试。

---

接下来在各个callback事件中进行检测，包括写入本地文件的时机和插入本地数据库的时机。由于所有的操作为同步，所以需要循环收集耗时然后一起打印：

不出所料的是所有耗时都集中在本地数据库部分。io也占了一部分。虽然io仅仅0.1秒，但是在后续的处理上也占了总处理时间的60%以上。

当然这不是什么大问题，当我们分包完成以后，这部分耗时都会被删除（云端版），至于本地版，在拥有便捷性的同时总是会失去一些什么 🚬

[SAKURA-CAT]

另一方面，在源码中，第一次上传指标是同步的（在子线程中），这是目前后端存在的瓶颈，具体就是表现在第一次上传指标后安全关闭实验的等待时间会比较久。

[SAKURA-CAT]

至于本地版，在拥有便捷性的同时总是会失去一些什么 🚬

其实这块核心还是在于数据库操作是同步的，python本身对异步协程的支持不太好，如果要优化本地版，则需要将本地版的数据库操作改成异步。

[SAKURA-CAT]

分包之后cloud的效果：

[SAKURA-CAT]

#843

[Zeyi-Lin]

@bojone swanlab==0.5.0，可以测试一下性能