Tedious: 使用 FILESTREAM 插入 varbinary(max) col 或从该列读取需要 10 秒

嗨@samaniamsam ，

感谢您指出了这一点。 我认为这可能是由于令牌解析是如何在 Tedious 中实现的，即有很多异步回调占用了大量内存，这在使用 varbinary(max) 和可能 varchar(max) 时变得更加如此。 我们确实有计划重构 Tedious 中的实现方式，以在不久的将来提高性能。

@arthurschreiber和@MichaelSun90你有什么想法？

嗨@sammaniamsam ，我只是好奇您使用的是哪个版本的 Tedious 会导致这个性能瓶颈？ #1006

@IanChokS我正在使用“^5.0.3”

好的，在筛选完所有当前未解决的问题之后，很明显性能阻塞是一个常见问题（例如，#879、#781、#475、#467、#319、#303）。 目前，我们的路线图上有一些东西，例如实现始终加密功能、改进的数据类型验证/转换、可插入身份验证提供程序以及重构当前数据类型。 但是基于提出的问题，这个性能块似乎是人们在使用 乏味时面临的最常见的障碍。 我正在与 Arthur 和团队讨论需要优先考虑哪些工作，所以如果你觉得提高性能是你希望看到的最大变化，请留下一个赞或评论你对我们应该如何前进的想法。 任何反馈都会有很大帮助！ 🙇

WIP 修复性能问题 -> #1037

描述：#1038

嗨@sammaniamsam ，我们最近合并了#1049、#1044、#1037，希望能提高性能。 您是否介意再次针对最新的 master 分支运行基准测试，并让我们知道您是否看到最终的性能有所提高？

谢谢！ 🙇

编辑：它尚未在 npm 上发布，但更改在当前 master 分支中

@IanChokS绝对！ 谢谢你们照顾这个。 我期待着测试新的改进。

@IanChokS结果在下表中。 如果您有任何问题，请告诉我。

方法 | 繁琐的版本 | 文件数 | 尺寸 | 执行时间（毫秒）
-- | -- | -- | -- | --
阅读 | ^6.3.0 | 1 | 23.33 MB | 2435.834
阅读 | ^6.3.0 | 2 | 46.66 MB | 5008.435
阅读 | ^6.3.0 | 3 | 136.5 KB | 329.727
插入 | ^6.3.0 | 2 | 11.9 MB | 4316.95
插入 | ^6.3.0 | 4 | 59 KB | 42.864
阅读 | 最新硕士 | 1 | 23.33 MB | 2771.478
阅读 | 最新硕士 | 2 | 46.66 MB | 4877.394
阅读 | 最新硕士 | 3 | 136.5 KB | 93.575
插入 | 最新硕士 | 2 | 11.9 MB | 2535.267
插入 | 最新硕士 | 4 | 59 KB | 43.886

看起来不错！ 它与我们的插入结果相匹配。 例如，内存使用量减少了一半。

我们肯定会在未来寻求增加阅读时间💪

:tada: 这个问题已经在 8.1.0 版本中解决了:tada:

该版本适用于：

• npm 包（ @latest dist-tag）
• GitHub 发布

你的语义释放机器人 :package::rocket: