Re: Removing xrdb for 10% startup win?

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Sun, 2005-08-28 at 03:27 +0200, Lorenzo Colitti wrote:
> Owen Taylor wrote:
> > xrdb is first called by the X init scripts, then later *again* by
> > gnome-settings-daemon.
> > xrdb is also invoked by the default GNOME Xsession script:
> > [...]
> > I'm guessing that possibly Lorenzo didn't have any of these files
> > in his test setup. (Fedora always has a system Xresources file. I don't
> > know the situation for other distributions.)
> 
> Indeed: I didn't see this because I was compiling trunk gdm2 on Debian, 
> in which /etc/X11/Xresources is a directory containing three resource 
> files, which the default gdm setup doesn't see (it expects 
> /etc/X11/Xresources to be a file). In the stock Debian configuration, 
> xrdb is called by gdm as part of the default session (three times), and 
> then again by gnome-settings-daemon.
> 
> > To put it another way - we don't get the win by just removing
> > grdb, we need to get rid of xrdb calling cpp altogether.
> 
> The same startup performance win could be had by switching the system 
> startup scripts so that they call xrdb with the -nocpp switch. This 
> would probably not do any harm: at least on Debian, the stock X11 
> session files do not contain any #defines, and I expect this to be 
> similar in other distributions. If this were done, it would be trivial 
> to switch the code in gnome-settings-daemon so it didn't require cpp to run.
> 
> I don't know what other people think, but to me it just seems silly that 
> the whole C compiler is loaded when starting up X, just because there 
> /might/ be some #define statements somewhere, which, even if they were 
> present, could be replaced by a simple sed command in 99% of cases.

  The only problem is user resources containing #define's.  I am one of
those users.  If you remove the cpp filter my ~/.Xresources will
probably stop working.  Now, I will know what to do because I read this
list, but many other users will be left wondering why GNOME has broken
their X resources.

  So how about GNOME doing this instead:

	1- stat(~/.Xresources) --> if fail return
	2- stat(~/.Xresources.compiled)
	3- if "~/.Xresources.compiled does not exist" OR
"~/.Xresources.compiled older than ~/.Xresources":
		3.a) run "cpp ~/.Xresources -o ~/.Xresources.compiled"
	4- Run "xrdb -nocpp ~/.Xresources.compiled"

  It runs cpp once, and any time ~./Xresources changes, but otherwise
cpp is skipped altogether.  My suggestion is pretty obvious, I guess,
but someone had to spell it out for the record :)

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic