Tedious: FILESTREAMを使用してvarbinary（max）colに挿入するか、その列から読み取るのに数十秒かかります

こんにちは@sammaniamsam 、

これを指摘してくれてありがとう。 これは、Tediousでトークン解析がどのように実装されているか、つまり、varbinary（max）とおそらくvarchar（max）を使用すると、より多くのメモリを消費する非同期コールバックが多数あるためだと思います。 近い将来、パフォーマンスを向上させるために、Tediousでの実装方法をリファクタリングする計画があります。

@ arthurschreiber 、 @ MichaelSun90についてどう思いますか？

こんにちは@sammaniamsam 、このパフォーマンスのボトルネックの原因となるTediousのバージョンを使用しているのが気になりますか？ ＃1006

@IanChokS 「^ 5.0.3」を使用しています

現在未解決の問題をすべて調べた後、パフォーマンスの低下が一般的な問題であることは明らかです（たとえば、＃879、＃781、＃475、＃467、＃319、＃303）。 現在、ロードマップには、Always Encrypted機能の実装、データ型の検証/変換の改善、プラガブル認証プロバイダー、現在のデータ型のリファクタリングなどがあります。 しかし、提起されている問題に基づくと、このパフォーマンスブロックは、退屈な使用時に人々が直面する最も一般的な障壁のようです。 アーサーとチームとどの作業を優先する必要があるかについて話し合っているので、パフォーマンスの向上が最大の変化であると感じた場合は、いいねを残すか、私たちがどのように前進すべきかについての考えをコメントしてください。 フィードバックは大いに役立ちます！ 🙇

パフォーマンスの問題を修正するためのWIP->＃1037

説明：＃1038

こんにちは@sammaniamsam 、最近＃1049、＃1044、＃1037をマージしました。これにより、パフォーマンスが向上することを願っています。 最新のマスターブランチに対してベンチマークを再度実行し、パフォーマンスが向上したかどうかをお知らせください。

ありがとう！ 🙇

編集：npmにはまだリリースされていませんが、変更は現在のマスターブランチにあります

@IanChokS絶対に！ これを世話してくれてありがとう。 新しい改善点をテストすることを楽しみにしています。

@IanChokS結果は以下の表にあります。 ご不明な点がございましたら、お気軽にお問い合わせください。

方法| 面倒なバージョン| ファイル数| サイズ| 実行時間（ms）
-| -| -| -| -
読む| ^ 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：