2008年11月07日
川俣晶の縁側ソフトウェア技術雑記total 13391 count

System.IO.Directory.GetFiles メソッド の問題点とは何か

Written By: 川俣 晶連絡先

 kkamegawaさんの.NET Framework 4.0 BCLの続きより。

一万個くらいのファイルがあるフォルダに対してGetFiles()は確かに想定していない話でした。というか、システム上、作られないようにできるだけ考えておきますが、想像の斜め上のことをやってしまう方は確かにいます。

 少し誤解されているようですが。

 まず、1フォルダ1万個のファイルというのは、そう簡単に発生する状況ではありませんが、実運用上要求されることは珍しくありません。特にXMLの世界では「よくある状況」と思って良いと思います。1件のデータを1つのXMLファイルとして扱っていて、1万件のデータがあればそれだけでそうなります。実際、過去には6万個ぐらい(だったと思うが記憶は定かではない)のXMLファイルを1つのフォルダに入れて扱ったことがありますが、これは公的に定められた手続き上必須の要件でした。

 さすがにこのクラスになるとかなり重いので、無理がないとは言いません。しかし、現在も約1万個のファイルを含むフォルダを持つプログラムを運用していますが、このレベルなら十分に運用できる範囲だと思います。だから、1フォルダ1万個のファイルは「想像の斜め上」ではなく、ごく単純に「普通のシステム設計上ありえる状況」でしかありません。

 ただし、RDB技術者であればわざわざ小さなファイルを多数作成する可能性は薄く、「RDB技術者にとっての普通」ではあり得ないかもしれません。しかし、RDBがシステム構築の1つの選択肢でしかない以上、RDBを選ばなかったシステムも世の中にはあって、それはRDB技術者の常識では動いていません。

 さてここからが本題。

 私が問題にしたのは、ファイルが多いという異常状況下での動作遅延ではありません。

 単純に、Win32 APIのFindFirstFile等APIと.NET FrameworkのSystem.IO.Directory.GetFiles メソッドを比較したとき、後者には歴然とした性能上の問題が存在するという話です。

 具体的には「列挙ではなく、インスタンスを返す」という点です。

 これは以下のような問題を発生させます。

  • 全てのファイルを調べ終わるまで制御が戻ってこない
  • 全てのファイル名を格納するメモリが常に消費される

 前者は、全ファイルを調べなくても完了できる処理を最適化できないことを意味します。後者は、単に発見したファイルに対して何かの処理を行うだけの場合、不必要なメモリを要求することを意味します。メモリ消費量が不必要に多くなることは、必要なデータがCPUのキャッシュに乗らない可能性が高くなり、全般的なパフォーマンスのスローダウンが起こる可能性もあり得ます。このような問題は、小さなテストプログラムでは顕在化しないかもしれませんが、意識する価値のある問題だと思っています。

Facebook

このコンテンツを書いた川俣 晶へメッセージを送る

[メッセージ送信フォームを利用する]

メッセージ送信フォームを利用することで、川俣 晶に対してメッセージを送ることができます。

この機能は、100%確実に川俣 晶へメッセージを伝達するものではなく、また、確実に川俣 晶よりの返事を得られるものではないことにご注意ください。

このコンテンツへトラックバックするためのURL

http://mag.autumn.org/tb.aspx/20081107135641
サイトの表紙【技術雑記】の表紙【技術雑記】のコンテンツ全リスト 【技術雑記】の入手全リスト 【技術雑記】のRSS1.0形式の情報このサイトの全キーワードリスト 印刷用ページ

管理者: 川俣 晶連絡先

Powered by MagSite2 Version 0.36 (Alpha-Test) Copyright (c) 2004-2021 Pie Dey.Co.,Ltd.