今井です。
On Mon, 30 Jul 2001 19:40:18 +0900
三田 英之 <cg3h-mt@xxxxxxxxxx> wrote:

(snip)
> > しかし、1フォルダ中に10000通くらい溜ってくると、GTK+の実装の都合で
> > 急激に速度が低下します。
> 
> あと、これは OS に (というかファイルシステムの実装に) 依存すると思うの
> ですが、Linux の ext2 ファイルシステムだと同一ディレクトリ内にある
> ファイル数が1000のオーダーになってくるとずいぶんと遅くなる気がします。
> 
> # B-Tree とかを使ったファイルシステムならそうでもないんでしょうけれど。
ファイルシステムの問題はGTK+の問題にくらべるとたいしたことでは
ないと思います。
[sylpheed:02100]より:
However, this does not really increase the speed of folder opening that much. Th
e problem is that GtkCTree uses inefficient O(N^2) algorithms; here is a part fr
om the gprof output (after applying the buffering patch):

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
 18.35      6.06     6.06                             g_list_position
  5.63      7.92     1.86                             gtk_ctree_link
  4.90      9.54     1.62                             procmsg_write_cache
  4.63     11.07     1.53                             read
  3.88     12.35     1.28                             vfprintf
  3.30     13.44     1.09                             _IO_new_file_xsputn
  3.09     14.46     1.02                             gtk_type_is_a
  2.91     15.42     0.96                             write
  2.47     16.23     0.81                             fwrite
  2.12     16.93     0.70                             set_cell_contents

More than 24% of time is spent in g_list_position() and gtk_ctree_link() (which 
calls g_list_position). The bad thing is that because of O(N^2) behavior, GtkCTr
ee becomes even more inefficient in larger folders. Unfortunately, the GtkCTree 
data structure is designed in such a way that this is unavoidable.
__引用終わり。

-- 
Yoichi Imai
yoichi@xxxxxxxxxx
http://y-imai.good-day.net/