November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 10% redisplay speed up... 24 years, 6 months

Ben Wing

Thank you so much for doing this! We need WAY more profiling done of XEmacs. Why don't you post exactly the steps you took in order to get the profiling output, as well as the relevant part of the output itself? I think people are scared off of profiling because XEmacs is big and does nonstandard things with its executable, and they don't want to figure out how to do it. I really really think you should implement your comment about memcmp(). Do something like this: 1. Move the non-compared fields to the end (Bufpos and Endpos, I think) and create an extra substructure that includes everything else. This means you have to change all the places in the code that access the fields, but there will be no slowdown as a result of this. 2. Give the union a name, and make sure it's bzero()d whenever it's changed. (This should cause negligible slowdown, right? The structure is compared *much* more often than changed, I presume.) 3. Replace compare_runes() with a memcmp() of the substructure and a call to WINDOW_FACE_CACHEL_DIRTY(). ben Jan Vroonhof wrote: > ...and for free too! If I count correctly the change to struct rune > does not change its size at all. > > A while ago I ran XEmacs under C level profiling and this is the result > > time xemacs.old -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 93.300u 2.080s 1:41.36 94.1% 0+0k 0+0io 1387pf+0w > time xemacs.new -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 82.100u 2.030s 1:27.44 96.2% 0+0k 0+0io 1488pf+0w > time xemacs.new -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 80.910u 2.280s 1:28.60 93.8% 0+0k 0+0io 1386pf+0w > time xemacs.old -vanilla -eval '(progn (loop repeat 10 do (hanoi 6)) (kill-emacs))' > 94.700u 2.030s 1:41.31 95.4% 0+0k 0+0io 1387pf+0w > > 1999-11-16 Jan Vroonhof <vroonhof(a)math.ethz.ch> > > * src/redisplay-output.c (compare_runes): Add comments about > results from profiling. > > * src/redisplay.h (struct rune): Do not use bitfields for members. > (struct rune): Add various comments about further optimizations. > > Index: src/redisplay-output.c > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-output.c,v > retrieving revision 1.11.2.19 > diff -u -u -r1.11.2.19 redisplay-output.c > --- redisplay-output.c 1999/10/15 10:11:50 1.11.2.19 > +++ redisplay-output.c 1999/11/16 21:05:23 > ＠＠ -190,6 +190,27 ＠＠ > /* Do not compare the values of bufpos and endpos. They do not > affect the display characteristics. */ > > + /* Note: (hanoi 6) spends 95% of its time in redisplay, and about > + 30% here. Not using bitfields for rune.type alone gives a redisplay > + speed up of 10%. > + > + #### In profile arcs run of a normal Gnus session this function > + is run 6.76 million times, only to return 1 in 6.73 million of > + those. > + > + In addition a quick look GCC sparc assembly shows that GCC is not > + doing a good job here. > + 1. The function is not inlined (too complicated?) > + 2. It seems to be reloading the crb and drb variables all the > + time. > + 3. It doesn't seem to notice that the second half of these if's > + are really a switch statement. > + > + So I (JV) conjecture > + > + #### It would really be worth it to arrange for this function to > + be (almost) a single call to memcmp. */ > + > if ((crb->findex != drb->findex) || > (WINDOW_FACE_CACHEL_DIRTY (w, drb->findex))) > return 0; > Index: src/redisplay.h > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.h,v > retrieving revision 1.7.2.13 > diff -u -u -r1.7.2.13 redisplay.h > --- redisplay.h 1999/10/26 05:48:53 1.7.2.13 > +++ redisplay.h 1999/11/16 21:05:46 > ＠＠ -91,6 +91,13 ＠＠ > but control characters have two -- a ^ and a letter -- and other > non-printing characters (those displayed in octal) have four. */ > > +/* WARNING! In compare_runes (one of the most heavily used functions) > + two runes are compared. So please be careful with changes to this > + structure. See comments in compare_runes. > + > + #### This should really be made smaller. > +*/ > + > typedef struct rune rune; > struct rune > { > ＠＠ -105,10 +112,6 ＠＠ > each of the face properties in this > particular window. */ > > - short xpos; /* horizontal starting position in pixels */ > - short width; /* pixel width of rune */ > - > - > Bufpos bufpos; /* buffer position this rune is displaying; > for the modeline, the value here is a > Charcount, but who's looking? */ > ＠＠ -116,11 +119,26 ＠＠ > /* #### Chuck, what does it mean for a rune > to cover a range of pos? I don't get > this. */ > - unsigned int cursor_type :3; /* is this rune covered by the cursor? */ > - unsigned int type :3; /* type of rune object */ > + /* #### This isn't used as an rvalue anywhere! > + remove! */ > + > + > + short xpos; /* horizontal starting position in pixels */ > + short width; /* pixel width of rune */ > + > + > + unsigned char cursor_type; /* is this rune covered by the cursor? */ > + unsigned char type; /* type of rune object */ > + /* We used to do bitfields here, but if I > + (JV) count correctly that doesn't matter > + for the size of the structure. All the bit > + fiddling _does_ slow down redisplay by > + about 10%. So don't do that */ > > union /* Information specific to the type of rune */ > { > + /* #### GLyps are are. Is it really necessary to waste 8 bytes on every > + rune for that?! */ > /* DGLYPH */ > struct > {

2 participants
1 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 24 years, 6 months

Hrvoje Niksic

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > It's not that I insist on the -internal suffix. If we want to have > -1 suffixes instead or whatever it's fine with me. Argh. :-) You're missing the point. Just like -internal, the -1 suffix screams "DON'T USE ME YOU'LL BE SORRY" to the user. If that's what you want to do, fine. If not, not. > - a low-level layer implemented in C which is to be kept as small as > possible and provides basic wrappers around the LDAP C API > > - a higher-level layer written in Lisp which provides functions to > access LDAP. This higher-level layer should be the preferred (not > exclusive) way for package programmers to use LDAP. Therefore > those functions should be safe, efficient and general enough for > most programmers to use This is good design, except that if Lisp programmers are ever expected to use the lower-level API, you should remove the "-internal" suffix and choose better names for functions.

1 participants
0 comments

Re: Timer does not delay 24 years, 6 months

Jan Vroonhof

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > I assume this is using the timer.el compatbility package. Yes. But it doesn't matter. I can see the problem here too when I do make-itimer directly. Jan P.S. Itimers seem to be broken in 21.1.x, see http://www.xemacs.org/list-archives/xemacs/9911/msg00442.html I am seeing that using Gnus can sometimes leave tens of timers lying around (this makes XEmacs suck up CPU time like mad). That could be related. Which reminds me, there is a bugfix for edit-itimer that I still need to submit.

1 participants
0 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 24 years, 6 months

Oscar Figueiredo

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> wmperry(a)aventail.com (William M. Perry) writes: >> I was thrown off by the fact that the LDAP routines you are supposed >> to use if you make the connection your self are all named >> 'xxx-internal', which means (to me) 'DO NOT USE THIS DIRECTLY', etc. Hrvoje> I was begging Oscar not to use the name -internal if he doesn't mean Hrvoje> it, but he convinced me that the -internal routines exist for the ease Hrvoje> of implementation, and that the routines a Lisp user should call are Hrvoje> the ones defined in ldap.el. Hrvoje> Oscar, what's the current status of your API? Please see my other post. It's not that I insist on the -internal suffix. If we want to have -1 suffixes instead or whatever it's fine with me. What's actually important is that the API is designed in two layers: - a low-level layer implemented in C which is to be kept as small as possible and provides basic wrappers around the LDAP C API - a higher-level layer written in Lisp which provides functions to access LDAP. This higher-level layer should be the preferred (not exclusive) way for package programmers to use LDAP. Therefore those functions should be safe, efficient and general enough for most programmers to use This design has been discussed a while ago and has even been presented at the m17n99 conference. There has been no change in philosophy since then. Oscar

1 participants
0 comments

Re: Martin makes man & Makefile makeover 24 years, 6 months

Adrian Aichner

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> - Make sources compatible with makeinfo 4.0 *and* 3.12. Hello Martin, trying to generate info.info using texinfo-3.12 on Windows NT I get this error: cd d:\tmp\21.2\xemacs\man\ d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe info.texi Compilation started at Thu Nov 18 10:55:16 1999 +0100 (W. Europe Standard Time) Making info file `../info/info.info' from `info.texi'. info.texi:69: No matching `＠end ifnottex'. info.texi:77: Unmatched `＠end'. makeinfo.exe: Removing output file `../info/info.info' due to errors; use --force to preserve. Compilation exited abnormally with code 2 at Thu Nov 18 10:55:18 What do you make of this? Can you generate .info files for all .texi files in the latest 21.2 CVS sources using cd c:\XEmacs\xemacs-packages\etc\psgml\ d:\tmp\texinfo-3.12\makeinfo\makeinfo.exe --version Compilation started at Thu Nov 18 11:28:48 1999 +0100 (W. Europe Standard Time) makeinfo (GNU texinfo 3.12) 1.68 Copyright (C) 1998 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. Compilation finished at Thu Nov 18 11:28:48 ? Best regards, Adrian

1 participants
0 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 24 years, 6 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > I was thrown off by the fact that the LDAP routines you are supposed > to use if you make the connection your self are all named > 'xxx-internal', which means (to me) 'DO NOT USE THIS DIRECTLY', etc. I was begging Oscar not to use the name -internal if he doesn't mean it, but he convinced me that the -internal routines exist for the ease of implementation, and that the routines a Lisp user should call are the ones defined in ldap.el. Oscar, what's the current status of your API?

1 participants
0 comments

Re: Timer does not delay 24 years, 6 months

Jan Vroonhof

Pete Forman <gsez020(a)kryten.bedford.waii.com> writes: > This code should post a message after a delay of 10 seconds. Only the > third method (sleep-for) works. The first two execute the message > function immediately, or very quickly. > > (run-at-time 10 nil 'message "pwf run-at-time") > ("itimer-0" 9.999781 nil message nil t ("pwf run-at-time") (0 0 0)) The problem seems to be that only the first time out isn't working... Strange...

3 participants
2 comments

Re: [21.2] LDAP add and delete functions + interrupt fixes 24 years, 6 months

Oscar Figueiredo

>>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: William> karlheg(a)cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: >> >>>>> "Ben" == Ben Wing <ben(a)666.com> writes: >> Ben> Actually, Oscar, I was suggesting more simple changes, Ben> i.e. just make your API consistent with general Elisp API Ben> principles. >> Ben> For example: >> Ben> -- Instead of ldap-add-internal, just call it ldap-put and Ben> make it the advertised Ben> interface. There is no need to provide an interface like Ben> ldap-add that automatically does an open and a close, Ben> displays messages, looks for ldap-default-host, etc. Follow Ben> standard convention and make the caller do this. >> >> But then just about every program that uses it will need to define a >> wrapper function that does all that. William> The current ldap-add is very inneficient if you are going to be making William> anything other than _1_ modification, which isn't usually the case (at William> least when I use ldap :) Then we should make it better. I do not agree with Ben when he says that there is no need to provide an interface like ldap-add. As Karl stated, most applications will need to perform the same sequence of calls the same host parameters lookup, etc... Such an interface provides (or should provide) what the vast majority of programmers will want to do in a clean, safe and efficient way. Adding a record or performing a search always involves the same sequence of calls, we will avoid duplication and most of all, mistakes by providing good high-level functions. For instance, when using the ldap-*-internal functions, Bill forgot to use ldap-close. If he did, then most programmers will as well. William> I was thrown off by the fact that the LDAP routines you are supposed to use William> if you make the connection your self are all named 'xxx-internal', which William> means (to me) 'DO NOT USE THIS DIRECTLY', etc. Kind of like William> open-network-stream-internal and friends. That was indeed my intention. It's not that the ldap-*-internal should not be used by programmers at all, they're just not the preferred way to do things. Let me restate the rationale of the current API. I've had two goals when designing it. First I wanted the C code to be kept as small as possible, all complex argument processing being moved to the Lisp-level. Then I wanted to provide an API reminding the traditional LDAP command-line tools so that someone who knows LDAP wouldn't be put off by a new API. Therefore the C code is designed to provide the most basic wrappers around the LDAP API calls. The functions in ldap.el provide the preferred programmer interface. If they're not good enough then we should strive to make them better, not simply discard them. Oscar

1 participants
0 comments

Re: Martin makes man & Makefile makeover 24 years, 6 months

Adrian Aichner

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Hi Martin, building on Windows NT native I get as far as this: Wrote d:\tmp\21.2\xemacs\info\xemacs.info-19 Splitting Info file...done. Saving modified d:\tmp\21.2\xemacs\info\xemacs.info Wrote d:\tmp\21.2\xemacs\info\xemacs.info NMAKE : fatal error U1073: don't know how to make '..\man\lispref\index.perm' Stop. Compilation exited abnormally with code 2 at Thu Nov 18 00:44:43 Have you removed $(MANDIR)\lispref\index.perm ? nt/xemacs.mak has this rule: $(INFODIR)\lispref.info: $(MANDIR)\lispref\lispref.texi copy $(MANDIR)\lispref\index.perm $(MANDIR)\lispref\index.texi $(MAKEINFO) $** Why should $(MANDIR)\lispref\index.perm be discontinued? Regards, Adrian Martin> * internals/Makefile: Martin> * xemacs/Makefile: Martin> * lispref/Makefile: Martin> * new-users-guide/Makefile: Martin> * lispref/index.perm: Martin> * lispref/index.unperm: Martin> * lispref/permute-index: Martin> * internals/index.perm: Martin> * internals/index.unperm: Martin> Remove these Makefiles. Martin> Include all functionality in man/Makefile. Martin> Support only non-permuted indexes for simplicity. Martin> * emodules.texi: Martin> - TeX doesn't tolerate `_' in variable names; use `-' instead. Martin> * lispref/commands.texi:

2 participants
1 comments

Re: Char-related crashes (hopefully) fixed 24 years, 6 months

Hrvoje Niksic

[ I've added Ben to Cc because he AFAIR doesn't read xemacs-beta. ] "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Can somebody give a bunch of examples where using integers as > characters is useful? I can. Here are four: (let ((letter ?a)) (while (< letter ?z) ... do something with letter ... (incf letter))) ;; The above example can be coded more nicely after my changes to ;; translate-region (which see), but we're talking legacy code here. (defun turn-a-into-b () (let ((string (make-string 256 ?\0))) (dotimes (i 265) (aset string i i)) (aset string ?a ?b) (translate-region (point-min) (point-max)))) (defvar foo-legal-chars (mapcar #'int-char '(... a bunch of numeric values imported from somewhere ...))) (defun stupid () (let ((number (read-number "Please enter a number: "))) (message "The character that corresponds to %d is: %c" number (int-char number)))) I could think of more of such, but I don't really see the point. Remember that characters have been indistinguishable from characters within Emacs for *decades*. > For that matter, where they are actually used? Ben said "backward > compatibility," but I haven't seen this used, and I don't really > know how to grep for it. I have grepped for int-char, int-to-char, > char-int, and char-to-int and they're pretty rare in the core and > package code (2/3 of it) that I have. The ones without them are even worse because they are implicit. See my examples. > The only one that I ever use is the C-q hack for inserting > characters by code value at the keyboard, and that could arguably > (and in Japanese invariably is) delegated to an input method which > would know about language environment (and return a true character). Some of us don't do input methods. But that's beside the point, because C-q can as well use make-char or whatever. > We already have primitives for efficient case conversion ...which don't work. More about that in a separate message.

2 participants
1 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta November 1999