[mdk-re] About Mutt

Сб Апр 7 23:12:12 MSD 2001

On Sat, 7 Apr 2001 10:50:41 +0400
Pavel Marakhovsky <_troggy_ на mtu-net.ru> wrote:

> On Sat, 7 Apr 2001 11:23:59 +0600
> Igor Solovyov <is13 на inbox.ru> wrote:
> 
> > Hi!
> > On Sat, 7 Apr 2001 07:41:48 +0400
> > Yura Zotov <yz-news на mail.ru> wrote:
> > 
> > > Решил я окончательно и бесповоротно переехать на Mutt, так как
> падучесть
> > > Stuphead уже достала. Впечатление от Mutt очень хорошее. Но вот один
> > 
> > А Sylpheed не пробовали?
> 
> Согласен.... Sylpheed получше будет.... Только вот никто не знает как
> заставить его быстрее работать
> с большим кол-вом сообщений (ALTLinux/Mandrake - 13051), а то и при
> чтении из mbox и при заходе
> в папку сортирует, и это как-то очень долго... несколько минут точно...

Первый раз слышу жалобы, что Sylpheed работает медленно. Вы Mahogany видели? Вот это уж тормоз так тормоз :-)

Но тем не менее напустил на Sylpheed -pg и gprof. Вот верхушка получившейся статистики (просто попеременно открывались две папки, в одной порядка 3400 сообщений):

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 41.56     13.13    13.13                             __mcount_internal
  9.69     16.19     3.06   770262     3.97     3.97  read
  9.09     19.06     2.87                             g_list_position
  3.67     20.22     1.16                             mcount
  1.99     20.85     0.63    70560     8.93    27.80  procmsg_write_cache
  1.87     21.44     0.59  1540231     0.38     0.66  _IO_new_file_xsputn
  1.77     22.00     0.56                             gtk_ctree_link
  1.68     22.53     0.53   107395     4.94    10.71  vfprintf
  1.27     22.93     0.40                             set_cell_contents
  1.14     23.29     0.36   459393     0.78     0.78  strcpy
  1.14     23.65     0.36     5550    64.86    64.86  write
  1.14     24.01     0.36                             gtk_type_is_a
  1.04     24.34     0.33  1538540     0.21     0.95  fwrite
  1.01     24.66     0.32   481769     0.66     0.71  chunk_alloc
  0.89     24.94     0.28                             g_str_hash
  0.76     25.18     0.24   473716     0.51     0.51  chunk_free
  0.73     25.41     0.23   769322     0.30     4.52  _IO_file_xsgetn
  0.66     25.62     0.21   443528     0.47     1.18  malloc
  0.63     25.82     0.20                             g_strdup
  0.60     26.01     0.19   769371     0.25     4.22  _IO_file_read
  0.60     26.20     0.19   769319     0.25     4.94  fread

Явный перебор с read(); такое впечатление, что буферизация отсутствует начисто (см. число fread в конце куска). После наложения прилагаемого патча (для 0.4.63cvs15, но, может быть, пойдет и на старых версиях - вроде бы это место не менялось) ситуация следующая:

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 38.97      9.17     9.17                             __mcount_internal
  9.94     11.51     2.34                             g_list_position
  4.08     12.47     0.96                             mcount
  2.76     13.12     0.65                             gtk_ctree_link
  2.55     13.72     0.60    96770     6.20    12.14  vfprintf
  2.38     14.28     0.56    63504     8.82    28.24  procmsg_write_cache
  1.91     14.73     0.45    65566     6.86     6.86  read
  1.87     15.17     0.44  1386377     0.32     0.63  _IO_new_file_xsputn
  1.66     15.56     0.39     4995    78.08    78.08  write
  1.57     15.93     0.37  1384686     0.27     0.98  fwrite
  1.53     16.29     0.36                             set_cell_contents
  1.40     16.62     0.33                             gtk_type_is_a
  1.27     16.92     0.30   414076     0.72     0.72  strcpy

Буферизация заработала. Это может быть проблемой glibc (у меня 2.1.3), так что, возможно, на glinc 2.2 это уже не требуется. После добавления setvbuf() у меня время работы mh_get_msg_list на этой папке сократилось с 0.51 с до 0.24 с. Но это, к сожалению, не вся проблема.

Чтобы не мешали всякие mcount, вот результаты для случая, когда -pg используется только в main.c:

  %   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
  1.85     17.55     0.61                             chunk_alloc

Таким образом, в лидерах с большим отрывом g_list_position и gtk_ctree_link. Посмотрев на исходник gtk_ctree_linк, нетрудно выяснить и причину - алгоритм с кучей последовательных поисков, O(N**2) (причем как раз случай вставки в конец самый плохой). g_list_position, похоже, тоже оттуда (лень было перебирать gtk с -pg, чтобы убедиться точно, но скорее всего все в GtkCTree).

Так что проблема в GTK+ :-(((