返信先: 4.2.4(先)ファイル追加時の動作

フォーラム TuneBrowser 4.2.4(先)ファイル追加時の動作 返信先: 4.2.4(先)ファイル追加時の動作

#1345
Tiki
キーマスター

薄々わかっていたことながら、その後分析してみても、12msの処理のうち明確に1ms以上かかっている処理などはなく、1ms未満の処理を数カ所改善して、合計で2ms程度短縮できたという感じです(それでもわたしとしては、実際に改善点を見つけられたのですから、達成感は感じられる成果ではあります)。(^^;

歳のせいか、とくに夜はどうしてもアプローチが局所的になりがちなのですが、今朝出勤のために歩いているときに、昨晩から見れば「まったく違う次元のやり方」をひとつ思いつきました。複数スレッドで並列処理をさせてみようと思います。

マルチコアの時代、そんなことは常套手段であって、実際にTuneBrowserもコンバータなど多くの箇所で分散処理を行っているのですが、個人的に、ひとつのデバイス(この場合はディスク)のI/Oに対して並列処理で攻め立てるのはあまり趣味ではなく、クローラに適用することはこれまで真剣には考えてきませんでした。クロールしている間はPCの負荷が不快な状態になってしまうことも考えられます。実際、その処理をしているRAMDecodeの並列読み込みも、あまり性能改善には至れていません(RAMDecodeはユーザ操作をトリガにしてバースト的に読み込むので、PCの状態には気を遣っていません)。

ただ、12msの内訳を調べていると、そこそこCPUの処理で時間がかかっているところもありそうなので、意味がないこともなさそうだと思い至りました。

この手の処理は不具合の温床になりがちですので、すこし時間がかかるかもしれませんが、検討してみようと思います。結果として、10,000ファイル120秒が110秒になった、という話で終わるかもしれませんが。

まだほかに「まったく違う次元のやり方」があるような気はするのですが、本当に無念なことに、思いつきません。

こうしたことを再検討する機会になったことは、感謝しています。(^^) 本件、返信無用です。