From owner-freebsd-gnome@FreeBSD.ORG Mon Mar 17 01:31:47 2008 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CEE9106566C for ; Mon, 17 Mar 2008 01:31:47 +0000 (UTC) (envelope-from ejcerejo@optonline.net) Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.4.199]) by mx1.freebsd.org (Postfix) with ESMTP id 1503A8FC21 for ; Mon, 17 Mar 2008 01:31:46 +0000 (UTC) (envelope-from ejcerejo@optonline.net) Received: from localhost (ool-44c03822.dyn.optonline.net [68.192.56.34]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with SMTP id <0JXU00EZOPKN3IG0@mta4.srv.hcvlny.cv.net> for freebsd-gnome@freebsd.org; Sun, 16 Mar 2008 21:31:36 -0400 (EDT) Date: Sun, 16 Mar 2008 21:31:33 -0400 From: "E. J. Cerejo" In-reply-to: <1204424514.1262.36.camel@shumai.marcuscom.com> To: Joe Marcus Clarke Message-id: <20080316213133.c1b5941f.ejcerejo@optonline.net> MIME-version: 1.0 X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20080301181608.5d393e02.ejcerejo@optonline.net> <1204415453.1262.26.camel@shumai.marcuscom.com> <20080301191214.58432ae0.ejcerejo@optonline.net> <1204417247.1262.29.camel@shumai.marcuscom.com> <20080301204637.74cfc75f.ejcerejo@optonline.net> <1204424514.1262.36.camel@shumai.marcuscom.com> Cc: freebsd-gnome@freebsd.org Subject: Re: Evolution crawls on FreeBSD X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 01:31:47 -0000 On Sat, 01 Mar 2008 21:21:54 -0500 Joe Marcus Clarke wrote: > > On Sat, 2008-03-01 at 20:46 -0500, E. J. Cerejo wrote: > > On Sat, 01 Mar 2008 19:20:47 -0500 > > Joe Marcus Clarke wrote: > > > > > > > > On Sat, 2008-03-01 at 19:12 -0500, E. J. Cerejo wrote: > > > > On Sat, 01 Mar 2008 18:50:53 -0500 > > > > Joe Marcus Clarke wrote: > > > > > > > > > > > > > > On Sat, 2008-03-01 at 18:16 -0500, E. J. Cerejo wrote: > > > > > > I'm running FreeBSD 7.0RC3 and I'm trying to figure out why evolution takes over a minute to start, there are no error messages if I run it from terminal window. First I was running 6.3 but I upgraded to 7.0 thinking that it might of solve the problem but it didn't. What amazes me is, I've got ubuntu installed on the same machine and it only takes 3 seconds to start, also it only takes 3 seconds to start in windows. Evolution running like this is completely worthless. Any ideas what might be causing this? Please respond to my email address also. > > > > > > > > > > This has been discussed on this mailing list before. The number of > > > > > plug-ins enabled in Evo slows down the load time as the loader is > > > > > spinning trying to load each plug-in. You should disable all unneeded > > > > > plug-ins. > > > > > > > > > > Joe > > > > > > > > > > -- > > > > > PGP Key : http://www.marcuscom.com/pgp.asc > > > > > > > > Plug-ins don't seem to have an effect when running it on ubuntu, all the plug-ins are enabled under ubuntu and still starts in 3 seconds. Are you trying to say that the FreeBSD loader is kind of primitive comparing to the linux loader? > > > > > > No. I'm saying that the tasks the FreeBSD loader performs takes longer > > > than the ones performed by the Linux loader. > > > > Well, I disabled all the plugins and still takes 40 seconds to open that's a lot longer than linux with all the plugins enabled. As far I'm concerned evolution is out of my list of programs, I still have my doubts about the real reason as to why it takes so long to open. In reality there's no real reason as to why a program will take so long to open, if that's the case evolution will loose a lot of users in the FreeBSD community. > > You're free to build Evolution and e-d-s with debugging symbols, and > watch it load in gdb if you don't believe me. Last time I did this, I > found most of the time spent in the loader. Any optimizations would > certainly be welcome. This patch for this evolution bug was posted in questions by lenzi and it solved that bug, I just thought you would like to know. It's not an evolution bug but glib20 instead. ---------------------------------x------------------------------ The problem is that glib on function g_module_load, searchs for a symbol g_module_check_init, g_module_unload... by default. It occurs that the evolution code, that will be loaded, does not have those functions available... so th glib (and dlsym) tries to find the symbol in every load module in memory... and doing so consumes all cpu for several seconds, for each load module.... ! coded a solution for gmodule that tests for those special symbos, and if found, uses dlsymb(RTLD_NEXT,....) instead of dlsym(handler....) so it will search a much less modules, and evolution will start in 3 seconds... (20 times less...) Of course the correct strategy is to correct code evolution module (libevolution-mail.so). will do next time.... modified file: /usr/ports/devel/glib20/files/patch-gmodule::gmodule-dl.c please note this is only a temporary fix... the correct solution is to fix the evolution module.... ============================================= --- gmodule/gmodule-dl.c.orig 2008-02-07 03:24:53.000000000 -0200 +++ gmodule/gmodule-dl.c 2008-03-11 18:53:44.000000000 -0300 @@ -73,6 +73,14 @@ #endif /* RTLD_GLOBAL */ +static char *special_names[]={ + "g_module_check_init", + "g_module_unload", + "e_plugin_lib_enable", + NULL +}; + + /* --- functions --- */ static gchar* fetch_dlerror (gboolean replace_null) @@ -106,6 +114,7 @@ static gpointer _g_module_self (void) { +#ifndef __FreeBSD__ gpointer handle; /* to query symbols from the program itself, special link options @@ -117,6 +126,9 @@ g_module_set_error (fetch_dlerror (TRUE)); return handle; +#else + return RTLD_DEFAULT; +#endif } static void @@ -141,9 +153,19 @@ { gpointer p; gchar *msg; + char **pn; fetch_dlerror (FALSE); - p = dlsym (handle, symbol_name); + + for (pn=special_names;*pn;pn++) { + if (!strcmp(*pn,symbol_name)) { + p=dlsym(RTLD_NEXT,symbol_name); + break; + } + } + + if (! *pn) + p = dlsym (handle, symbol_name); msg = fetch_dlerror (FALSE); if (msg) g_module_set_error (msg);