From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Sergey Vlasov To: mandrake-russian@altlinux.ru Subject: Re: [mdk-re] About Mutt Message-Id: <20010407231113.2ed6f580.vsu@mivlgu.murom.ru> In-Reply-To: <20010407105041.54dab25f._troggy_@mtu-net.ru> References: <20010407074148.A2056@vezyolka.dgap.mipt.ru> <20010407112359.60c4bae7.is13@inbox.ru> <20010407105041.54dab25f._troggy_@mtu-net.ru> X-Mailer: Sylpheed version 0.4.63cvs15 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Sender: mandrake-russian-admin@altlinux.ru Errors-To: mandrake-russian-admin@altlinux.ru X-BeenThere: mandrake-russian@altlinux.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: mandrake-russian@altlinux.ru List-Help: List-Post: List-Subscribe: , List-Id: Mandrake/RE discussion list List-Unsubscribe: , List-Archive: Date: Sat Apr 7 23:12:12 2001 X-Original-Date: Sat, 7 Apr 2001 23:11:13 +0400 Archived-At: List-Archive: List-Post: 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 wrote: > > > Hi! > > On Sat, 7 Apr 2001 07:41:48 +0400 > > Yura Zotov 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+ :-(((