slow make-frame + face initialization / importing x resources

slow make-frame + face initialization / importing x resources

[David Reitter]

I wonder if something can be done about the very slow `make-frame'.

Make-frame creates a frame-local copy of each face defined, and when  
you have a couple of faces defined for various modes, just a modest  
number of them (I have 700, defined with color-theme) will slow down  
frame creation to a point where it's just not tolerable any more.

Here's a bit of code to demonstrate the effect (with just "empty'  
faces):

(require 'cl)
(loop for X from 0 to 2000 do
       (make-face (intern (format "face%s" X))))
(let ((ti (current-time)))
   (loop for X from 0 to 10 do
	(make-frame))
   (print (format-time-string "%S" (time-since ti))))

The problem seems to be due to `x-create-frame-with-faces',  
specifically this form:

(dolist (face (delq 'default (face-list)))
       (condition-case ()
	  (progn
	    (face-spec-set face (face-user-default-spec face) frame)
	    (if (memq window-system '(x w32 mac))
		(make-face-x-resource-internal face frame))
	    (internal-merge-in-global-face face frame))
	(error nil)))

Frame creation time improves tremendously when I take out that call  
to `make-face-x-resource-internal'.
Is the import of x-resources necessary on Mac and Windows?
Also, is it necessary to do that every time a frame is created?  
Couldn't they be imported once at startup time?

Re: slow make-frame + face initialization / importing x resources

[Richard Stallman]

    Frame creation time improves tremendously when I take out that call  
    to `make-face-x-resource-internal'.
    Is the import of x-resources necessary on Mac and Windows?

I think it has to be done when the frame is created
because there is no chance to do it later.
Any of the faces used could be displayed in that frame
at any time.  And only the inner guts of redisplay will
notice when a face is first used in the frame.

Is it safe to set up the face for the frame
when it is first used in the frame?

Re: slow make-frame + face initialization / importing x resources

[Stefan Monnier]

>     Frame creation time improves tremendously when I take out that call  
>     to `make-face-x-resource-internal'.
>     Is the import of x-resources necessary on Mac and Windows?

> I think it has to be done when the frame is created
> because there is no chance to do it later.

How 'bout doing it earlier: i.e. share faces between all similar frames?


        Stefan

Re: slow make-frame + face initialization / importing x resources

[Stefan Monnier]

>     Frame creation time improves tremendously when I take out that call  
>     to `make-face-x-resource-internal'.
>     Is the import of x-resources necessary on Mac and Windows?

> I think it has to be done when the frame is created
> because there is no chance to do it later.

What if there are no face specifications in the X resources?

The current code checks every possible X resource setting for every face.
Why not list the resources instead and interpret them?
[ At least in my case it would probbaly be much faster since I shouldn't
have any settings in there]


        Stefan

Re: slow make-frame + face initialization / importing x resources

[David Reitter]

On 14 Jul 2007, at 02:55, Stefan Monnier wrote:

> The current code checks every possible X resource setting for every  
> face.
> Why not list the resources instead and interpret them?
> [ At least in my case it would probbaly be much faster since I  
> shouldn't
> have any settings in there]

Sounds like a good idea.  Almost all the time is spent on importing  
those X resources. I commented this out and it seems to work just  
fine for me (no X).
On Mac and Windows window systems, is there a reason why X resources  
should be supported in the first place?

Sharing the faces between frames would be good to. Can faces be  
deleted? No? This is probably why more and more faces accumulate over  
time (when you use something like color-theme, e.g.). What is the  
memory footprint of a single frame then?

Re: slow make-frame + face initialization / importing x resources

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Sat, 14 Jul 2007 21:53:38 +0100
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> On Mac and Windows window systems, is there a reason why X resources  
> should be supported in the first place?

I don't understand the question.  The Windows port reads X resources
from the Registry; why shouldn't we support that?

> Sharing the faces between frames would be good to.

What kind of sharing do you have in mind?  Faces are frame-specific,
so changing a face generally affects only the frame for which it is
changed.  If the suggested sharing will defeat this, I don't think
it's a good idea.

> Can faces be deleted? No? This is probably why more and more faces
> accumulate over time (when you use something like color-theme,
> e.g.).

If color-theme blindly adds faces instead of modifying existing ones,
then yes.  Does it actually do that?

> What is the memory footprint of a single frame then?

See struct frame defined on frame.h, but some of its members have
variable length.

Re: slow make-frame + face initialization / importing x resources

[Richard Stallman]

    > I think it has to be done when the frame is created
    > because there is no chance to do it later.

    How 'bout doing it earlier: i.e. share faces between all similar frames?

If there were no such thing as the functions set-face-XYZ, that would
work.  Those functions can be used to specify face attributes in a
single frame.  If you copy the faces from another similar frame, then
you'd get the wrong results if those functions were previously used to
change certain faces in that frame.

It could be that those functions are not a very useful feature
and should be eliminated.  We can ask whether any Lisp packages
outside Emacs really use them.

Another problem case is where you reevaluate an edited defface.
What was right on a similar frame now is not going to be right
in the future.

I am sure it is possible to take account of these things in
implementing new face initialization code.

    The current code checks every possible X resource setting for every face.
    Why not list the resources instead and interpret them?

That is true, but you still face the issues listed above
if you want to copy face attributes from another frame.

Re: slow make-frame + face initialization / importing x resources

[Stefan Monnier]

>> Sharing the faces between frames would be good to.
> What kind of sharing do you have in mind?  Faces are frame-specific,
> so changing a face generally affects only the frame for which it is
> changed.  If the suggested sharing will defeat this, I don't think
> it's a good idea.

I'm thinking of doing ref-counts and COW, so by default, if the new frame is
similar (e.g. on the same screen with the "same" frame parameters), so the
faces are inherited.  They can later get unshared if needed.

In typical usage patterns most frames are identical w.r.t faces and all
face-modification are applied uniformly to (almost) all frames.  So it should
be a valuable optimization.


        Stefan

Re: slow make-frame + face initialization / importing x resources

[Juanma Barranquero]

On 7/14/07, Eli Zaretskii <eliz@gnu.org> wrote:

> The Windows port reads X resources
> from the Registry;

And command line, with -xrm.

             Juanma

Re: slow make-frame + face initialization / importing x resources

[David Reitter]

On 14 Jul 2007, at 22:28, Eli Zaretskii wrote:

>> On Mac and Windows window systems, is there a reason why X resources
>> should be supported in the first place?
>
> I don't understand the question.  The Windows port reads X resources
> from the Registry; why shouldn't we support that?

Does the Windows port also save such settings to the registry, or are  
users meant to write thesis settings there manually?
The Carbon port reads such resources from a special .plist file, but  
it's unclear to me, why. Users would have to manipulate that (XML)  
file externally, and I don't understand how this would be easier or  
more sensible than configuring Emacs through the customization  
or .emacs interfaces.

> What kind of sharing do you have in mind?  Faces are frame-specific,
> so changing a face generally affects only the frame for which it is
> changed.  If the suggested sharing will defeat this, I don't think
> it's a good idea.

Share by default, but copy as soon as the face is changed. Stefan has  
described this in more detail.

> If color-theme blindly adds faces instead of modifying existing ones,
> then yes.  Does it actually do that?

It adds faces for all sorts of modes, whether you use those modes or  
not. That's how I have some 700 faces defined from just a couple of  
themes.
(I use different themes to visually distinguish frames depending on  
the major mode of the buffer that they display.)

Re: slow make-frame + face initialization / importing x resources

[Jan Djärv]

Stefan Monnier skrev:
>>> Sharing the faces between frames would be good to.
>> What kind of sharing do you have in mind?  Faces are frame-specific,
>> so changing a face generally affects only the frame for which it is
>> changed.  If the suggested sharing will defeat this, I don't think
>> it's a good idea.
> 
> I'm thinking of doing ref-counts and COW, so by default, if the new frame is
> similar (e.g. on the same screen with the "same" frame parameters), so the
> faces are inherited.  They can later get unshared if needed.
> 

What if X resources changed between creation of the first and second frame?

	Jan D.

Re: slow make-frame + face initialization / importing x resources

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Stefan Monnier skrev:
>>>> Sharing the faces between frames would be good to.
>>> What kind of sharing do you have in mind?  Faces are frame-specific,
>>> so changing a face generally affects only the frame for which it is
>>> changed.  If the suggested sharing will defeat this, I don't think
>>> it's a good idea.
>>
>> I'm thinking of doing ref-counts and COW, so by default, if the new frame is
>> similar (e.g. on the same screen with the "same" frame parameters), so the
>> faces are inherited.  They can later get unshared if needed.
>>
>
> What if X resources changed between creation of the first and second frame?

What if?  We don't track the changes of X resources in real-time for
the first frame, so what problem is there in not tracking them between
frames?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: slow make-frame + face initialization / importing x resources

[chad brown]

I believe that the Mac carbon port, at least, reads (pseudo) X  
resources to deal with customization before .emacs; specifically, so  
that windows can be graphically configured before mapped (which can  
result in ugly/annoying flashing, for example).

This points at a possible rethinking of ordering for starting,  
configuration, and window mapping, especially in light of the extra  
versatility of the multi-tty branch.  Of course, I'm not familiar  
with this part of emacs, so maybe the existing methods are already  
adequate, and I'm just ignorant of them.  Hmm...  I'll have to take a  
look at that again.

*chad


On Jul 15, 2007, at 2:35 AM, David Reitter wrote:

> The Carbon port reads such resources from a special .plist file,  
> but it's unclear to me, why. Users would have to manipulate that  
> (XML) file externally, and I don't understand how this would be  
> easier or more sensible than configuring Emacs through the  
> customization or .emacs interfaces.

Re: slow make-frame + face initialization / importing x resources

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Stefan Monnier skrev:
>>>>> Sharing the faces between frames would be good to.
>>>> What kind of sharing do you have in mind?  Faces are frame-specific,
>>>> so changing a face generally affects only the frame for which it is
>>>> changed.  If the suggested sharing will defeat this, I don't think
>>>> it's a good idea.
>>> I'm thinking of doing ref-counts and COW, so by default, if the new frame is
>>> similar (e.g. on the same screen with the "same" frame parameters), so the
>>> faces are inherited.  They can later get unshared if needed.
>>>
>> What if X resources changed between creation of the first and second frame?
> 
> What if?  We don't track the changes of X resources in real-time for
> the first frame, so what problem is there in not tracking them between
> frames?

Not a problem, but it is a change of behaviour.  If we do this change, we 
should make sure X resources are read only once.

	Jan D.

Re: slow make-frame + face initialization / importing x resources

[David Reitter]

On 15 Jul 2007, at 21:10, chad brown wrote:

> I believe that the Mac carbon port, at least, reads (pseudo) X  
> resources to deal with customization before .emacs; specifically,  
> so that windows can be graphically configured before mapped (which  
> can result in ugly/annoying flashing, for example).

For what it's worth, here's a patch from Aquamacs which avoids  
flashing/resizing. The initial frame is invisible, and only after the  
site- and user-specific settings are loaded, this frame is made  
visible. (In case of errors, the frame is made visible, too, of course.)





Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.368
diff -c -r1.368 startup.el
*** lisp/startup.el	15 Jul 2005 14:47:06 -0000	1.368
--- lisp/startup.el	17 Jul 2005 22:07:56 -0000
***************
*** 463,469 ****
   		  (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
   				    term)
   		      (setq default-frame-background-mode 'light)))
! 		(frame-set-background-mode (selected-frame)))))

   	;; Now we know the user's default font, so add it to the menu.
   	(if (fboundp 'font-menu-add-default)
--- 463,472 ----
   		  (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
   				    term)
   		      (setq default-frame-background-mode 'light)))
! 		(frame-set-background-mode (selected-frame))))
!
! 	  ;; time to make the frame visible (Aquamacs)
! 	  (make-frame-visible))

   	;; Now we know the user's default font, so add it to the menu.
   	(if (fboundp 'font-menu-add-default)
***************
*** 721,726 ****
--- 724,732 ----
       (and command-line-args
            (setcdr command-line-args args)))

+   ;; the initial frame is hidden in Aquamacs
+   (setq initial-frame-alist (cons '(visibility . nil) initial-frame- 
alist))
+
     ;; Under X Window, this creates the X frame and deletes the  
terminal frame.
     (when (fboundp 'frame-initialize)
       (frame-initialize))
***************
*** 1730,1735 ****
--- 1736,1744 ----
       ;; keystroke, and that's distracting.
       (when (fboundp 'frame-notice-user-settings)
         (frame-notice-user-settings))
+
+     ;; time to make the frame visible (Aquamacs)
+     (make-frame-visible)

       ;; If there are no switches to process, we might as well
       ;; run this hook now, and there may be some need to do it

Re: slow make-frame + face initialization / importing x resources

[Richard Stallman]

    I'm thinking of doing ref-counts and COW, 

Will your cow orkers offer any help in implementing this?

					      so by default, if the new frame is
    similar (e.g. on the same screen with the "same" frame parameters), so the
    faces are inherited.  They can later get unshared if needed.

If you're willing to redesign that much, I am sure you can make it
work.  While you are at it, you might be able to reduce the number
of levels of data structure that we have for faces.  That would
make things simpler and easier to maintain.

Re: slow make-frame + face initialization / importing x resources

[Richard Stallman]

    What if X resources changed between creation of the first and second frame?

I think Emacs keeps its own list of X resources internally.
(I am not certain -- I never studied the code in xrdb.c carefully.)
So Emacs ought to be able to tell when to consider new values.

With the sort of redesign that Stefan proposed, it is surely possible
to DTRT for any relevant factors there may be.  It was only the amount
of work involved in this that made me hesitate.

Re: slow make-frame + face initialization / importing x resources

[Stefan Monnier]

> The Carbon port reads such resources from a special .plist file, but it's
> unclear to me, why. Users would have to manipulate that (XML) file
> externally, and I don't understand how this would be easier or more
> sensible than configuring Emacs through the customization or
> .emacs interfaces.

I believe the advantage is that those X resource settings are applied before
the first frame is created, whereas those in .emacs are applied afterwards,
leading to transient artifacts.


        Stefan

Re: slow make-frame + face initialization / importing x resources

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Reitter <david.reitter@gmail.com>
> Date: Sun, 15 Jul 2007 10:35:59 +0100
> 
> Does the Windows port also save such settings to the registry, or are  
> users meant to write thesis settings there manually?

I don't think Emacs saves the settings to the Registry, but maybe I
don't understand the question--what Emacs interface saves X resources
on Unix?