* slow make-frame + face initialization / importing x resources @ 2007-07-13 17:55 David Reitter 2007-07-13 23:08 ` Richard Stallman 0 siblings, 1 reply; 19+ messages in thread From: David Reitter @ 2007-07-13 17:55 UTC (permalink / raw) To: emacs- devel 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-13 17:55 slow make-frame + face initialization / importing x resources David Reitter @ 2007-07-13 23:08 ` Richard Stallman 2007-07-14 1:21 ` Stefan Monnier 2007-07-14 1:55 ` Stefan Monnier 0 siblings, 2 replies; 19+ messages in thread From: Richard Stallman @ 2007-07-13 23:08 UTC (permalink / raw) To: David Reitter; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-13 23:08 ` Richard Stallman @ 2007-07-14 1:21 ` Stefan Monnier 2007-07-14 22:32 ` Richard Stallman 2007-07-14 1:55 ` Stefan Monnier 1 sibling, 1 reply; 19+ messages in thread From: Stefan Monnier @ 2007-07-14 1:21 UTC (permalink / raw) To: rms; +Cc: David Reitter, emacs-devel > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-14 1:21 ` Stefan Monnier @ 2007-07-14 22:32 ` Richard Stallman 0 siblings, 0 replies; 19+ messages in thread From: Richard Stallman @ 2007-07-14 22:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: david.reitter, emacs-devel > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-13 23:08 ` Richard Stallman 2007-07-14 1:21 ` Stefan Monnier @ 2007-07-14 1:55 ` Stefan Monnier 2007-07-14 20:53 ` David Reitter 1 sibling, 1 reply; 19+ messages in thread From: Stefan Monnier @ 2007-07-14 1:55 UTC (permalink / raw) To: rms; +Cc: David Reitter, emacs-devel > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-14 1:55 ` Stefan Monnier @ 2007-07-14 20:53 ` David Reitter 2007-07-14 21:28 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: David Reitter @ 2007-07-14 20:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, emacs-devel 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-14 20:53 ` David Reitter @ 2007-07-14 21:28 ` Eli Zaretskii 2007-07-15 1:29 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Eli Zaretskii @ 2007-07-14 21:28 UTC (permalink / raw) To: David Reitter; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-14 21:28 ` Eli Zaretskii @ 2007-07-15 1:29 ` Stefan Monnier 2007-07-15 13:50 ` Jan Djärv 2007-07-15 22:53 ` Richard Stallman 2007-07-15 8:26 ` Juanma Barranquero 2007-07-15 9:35 ` David Reitter 2 siblings, 2 replies; 19+ messages in thread From: Stefan Monnier @ 2007-07-15 1:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: David Reitter, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 1:29 ` Stefan Monnier @ 2007-07-15 13:50 ` Jan Djärv 2007-07-15 14:07 ` David Kastrup 2007-07-15 22:54 ` Richard Stallman 2007-07-15 22:53 ` Richard Stallman 1 sibling, 2 replies; 19+ messages in thread From: Jan Djärv @ 2007-07-15 13:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: David Reitter, Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 13:50 ` Jan Djärv @ 2007-07-15 14:07 ` David Kastrup 2007-07-15 22:02 ` Jan Djärv 2007-07-15 22:54 ` Richard Stallman 1 sibling, 1 reply; 19+ messages in thread From: David Kastrup @ 2007-07-15 14:07 UTC (permalink / raw) To: Jan Djärv; +Cc: David Reitter, Eli Zaretskii, Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 14:07 ` David Kastrup @ 2007-07-15 22:02 ` Jan Djärv 0 siblings, 0 replies; 19+ messages in thread From: Jan Djärv @ 2007-07-15 22:02 UTC (permalink / raw) To: David Kastrup; +Cc: David Reitter, Eli Zaretskii, Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 13:50 ` Jan Djärv 2007-07-15 14:07 ` David Kastrup @ 2007-07-15 22:54 ` Richard Stallman 1 sibling, 0 replies; 19+ messages in thread From: Richard Stallman @ 2007-07-15 22:54 UTC (permalink / raw) To: Jan Djärv; +Cc: david.reitter, eliz, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 1:29 ` Stefan Monnier 2007-07-15 13:50 ` Jan Djärv @ 2007-07-15 22:53 ` Richard Stallman 1 sibling, 0 replies; 19+ messages in thread From: Richard Stallman @ 2007-07-15 22:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: david.reitter, eliz, emacs-devel 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-14 21:28 ` Eli Zaretskii 2007-07-15 1:29 ` Stefan Monnier @ 2007-07-15 8:26 ` Juanma Barranquero 2007-07-15 9:35 ` David Reitter 2 siblings, 0 replies; 19+ messages in thread From: Juanma Barranquero @ 2007-07-15 8:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: David Reitter, emacs-devel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-14 21:28 ` Eli Zaretskii 2007-07-15 1:29 ` Stefan Monnier 2007-07-15 8:26 ` Juanma Barranquero @ 2007-07-15 9:35 ` David Reitter 2007-07-15 20:10 ` chad brown ` (2 more replies) 2 siblings, 3 replies; 19+ messages in thread From: David Reitter @ 2007-07-15 9:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 9:35 ` David Reitter @ 2007-07-15 20:10 ` chad brown 2007-07-15 22:08 ` David Reitter 2007-07-16 1:40 ` Stefan Monnier 2007-07-16 3:19 ` Eli Zaretskii 2 siblings, 1 reply; 19+ messages in thread From: chad brown @ 2007-07-15 20:10 UTC (permalink / raw) To: David Reitter; +Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 20:10 ` chad brown @ 2007-07-15 22:08 ` David Reitter 0 siblings, 0 replies; 19+ messages in thread From: David Reitter @ 2007-07-15 22:08 UTC (permalink / raw) To: chad brown; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 9:35 ` David Reitter 2007-07-15 20:10 ` chad brown @ 2007-07-16 1:40 ` Stefan Monnier 2007-07-16 3:19 ` Eli Zaretskii 2 siblings, 0 replies; 19+ messages in thread From: Stefan Monnier @ 2007-07-16 1:40 UTC (permalink / raw) To: David Reitter; +Cc: Eli Zaretskii, emacs-devel > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: slow make-frame + face initialization / importing x resources 2007-07-15 9:35 ` David Reitter 2007-07-15 20:10 ` chad brown 2007-07-16 1:40 ` Stefan Monnier @ 2007-07-16 3:19 ` Eli Zaretskii 2 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2007-07-16 3:19 UTC (permalink / raw) To: David Reitter; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2007-07-16 3:19 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-07-13 17:55 slow make-frame + face initialization / importing x resources David Reitter 2007-07-13 23:08 ` Richard Stallman 2007-07-14 1:21 ` Stefan Monnier 2007-07-14 22:32 ` Richard Stallman 2007-07-14 1:55 ` Stefan Monnier 2007-07-14 20:53 ` David Reitter 2007-07-14 21:28 ` Eli Zaretskii 2007-07-15 1:29 ` Stefan Monnier 2007-07-15 13:50 ` Jan Djärv 2007-07-15 14:07 ` David Kastrup 2007-07-15 22:02 ` Jan Djärv 2007-07-15 22:54 ` Richard Stallman 2007-07-15 22:53 ` Richard Stallman 2007-07-15 8:26 ` Juanma Barranquero 2007-07-15 9:35 ` David Reitter 2007-07-15 20:10 ` chad brown 2007-07-15 22:08 ` David Reitter 2007-07-16 1:40 ` Stefan Monnier 2007-07-16 3:19 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.