September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Mule performance penalty 26 years, 2 months

Greg Klanderman

Martin, One thing I noticed that is excruciatingly slow under MULE is selecting a large nnfolder group in Gnus. It is easily 100 times slower than non-MULE. I can recall it taking 25 minutes to enter my xemacs-beta group on an Ultra 1, compared to 10 seconds non-MULE. I've not used MULE since... this was last winter. greg >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> Martin> Hrvoje had trouble believing that the Mule penalty is only 30%. Martin> Obviously it depends on what you're doing. Martin> Martin> There will be places in the sources where switching from non-mule to Martin> mule will change an order-N algorithm to an order-N*N algorithm. I Martin> fixed such an algorithm in casefiddle.c. I am sure there are others. Martin> It is quite likely that using a fixed-width internal representation Martin> for characters instead of the current variable-width one is the right Martin> long-term strategy.

1 participants
0 comments

Re: [Bug] custom/widget; additional quotes w/ :type '(repeat sexp) 26 years, 2 months

Hrvoje Niksic

Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: > Sorry if this has been fixed since 21.0-b54 (custom-v1.9960-x) > > (defcustom cw-symbol-list nil "Test" > :type '(repeat (sexp :value nil))) > > (defcustom cw-string-list nil "Test" > :type '(repeat (sexp :value "nil"))) > > The custom buffer look like the following when adding elements to these > list: > > Cw Symbol List: * > [INS] [DEL] Lisp expression: "nil" > [INS] > > Cw String List: * > [INS] [DEL] Lisp expression: "\"nil\"" > [INS] Yikes! Disgusting. I think it's a bug with the printing process. We never did quite solve the problems with printer. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "A Real Programmer's code can awe with its fiendish brilliance, even as its crockishness appalls."

1 participants
0 comments

Re: Text properties slow down XEmacs 26 years, 2 months

Michael Sperber

>>>>> "Simon" == Simon Marshall <simon(a)gnu.org> writes: Simon> I don't know why Simon> XEmacs has non-duplicable text properties. Sounds like an oxymoron. They're extremely useful. For instance, I wrote a comint mode for Gambit, a Scheme interpreter (not really the one distributed with Gambit). Since Gambit must refer to the actual text of previous inputs, the mode makes everything before the current input line read-only. This, however, means that if anyone tries to copy-and-paste stuff from the inferior Gambit mode, the pasted text is read-only by default, which totally sucks. I've found not way in FSFmacs to fix this; in XEmacs, I simply make the relevant text property non-duplicable, and presto. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

[Bug] custom/widget; additional quotes w/ :type '(repeat sexp) 26 years, 2 months

Christoph Wedler

Sorry if this has been fixed since 21.0-b54 (custom-v1.9960-x) (defcustom cw-symbol-list nil "Test" :type '(repeat (sexp :value nil))) (defcustom cw-string-list nil "Test" :type '(repeat (sexp :value "nil"))) The custom buffer look like the following when adding elements to these list: Cw Symbol List: * [INS] [DEL] Lisp expression: "nil" [INS] Cw String List: * [INS] [DEL] Lisp expression: "\"nil\"" [INS] When setting the variables, their values look like ("nil") and ("\"nil\"") Unfortunatly, I just start using custom, so I cannot send a patch. - Christoph

1 participants
0 comments

Re: [Various] [bug] XEmacs and gpm: SIGTSTP resignalling loop? 26 years, 2 months

Jan Vroonhof

> I do not have enough programming experience to debug and fix the > problem myself. I am afraid the only way to solve this is running XEmacs (and libgpm) under a debugger and look at what happens. Even without much pogramming experience that should be doable. > I assume you work with current gpm (1.14) otherwise all bets are off. Karl, did you? Debian hamm seems to have 1.13. > If there is indeed a conflict, it is not a problem with gpm: we really > do it extra-extra clean way, calling back the original handler if > there is any. A conflict is possible (likely) however if the app > opens the gpm connection first and _then_ installs its own SIGTSTP > handler, overwriting ours. If that is the problem, merely changing > the order of initialisations should help. As far as grep can see XEmacs does not install its own SIGTSTP handler at all. Basically, all it does is send SIGTSTP to its whole program group if M-x suspend-emacs is called. > unless you can/want to modify Emacs internals, _and_ can find the one > very special place in in the Emacs code where to call GPM_DRAWPOINTER > from, the redisplay will clobber the pointer again. That will be at the end of the redisplay code, that should not be too difficult. > find that one special place, so I had the pointer visible through > drags. I am almost sure that piece of code is different for XEmacs. I don't think it is that different. > That said, I once added gpm support to GNU Emacs the dirty way (the > way XEmacs seems to do it now, judging by your info) I find the current way gpm is implemented (114 lines of C code, including comments and whitespace) in XEmacs very clean. It does not involve running another subprocess from lisp nor does it involve manufacturing events from lisp code. The latter is only possible as of 21.0 anyway and is very tricky to get right. Jan

1 participants
0 comments

Binary Kits? 26 years, 2 months

Andy Piper

So I've built 21.0, are we making binary kits or not? andy --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Text properties slow down XEmacs 26 years, 2 months

Hrvoje Niksic

I'm more and more convinced that our extent-based text properties interface is what is slowing XEmacs down for most practical purposes. Naturally, I count fontification of large buffers and Summary buffer creation as "practical purposes." Profiles of Summary creation have been published in the past so there is no need to rehash that. Let's look at a fontification profile instead. Where would you expect most time is being spent during fontification? My bet would be regexp-matching. Well, wrong! Here is the actual profile: Function Name Ticks %/Total Call Count ================================= ===== ======= ========== put-nonduplicable-text-property 251 34.958 31856 re-search-forward 131 18.245 16120 font-lock-fontify-keywords-region 113 15.738 1 (in garbage collection) 100 13.928 map-extents 94 13.092 13931 text-property-any 14 1.950 3787 get-text-property 9 1.253 1909 next-single-property-change 6 0.836 1909 ------------------------------------------------------------------ Total 718 100.00 One tick = 1 ms So, by *far* the most time (35%) is getting spent in the text-props code, in an XEmacs compiled *without* error checking. I suspect this code is much faster in FSF Emacs because they support text properties directly through the use of balanced trees, while we emulate them using non-overlapping extents, which are stored as a simple ordered list in the buffer. It's kind of sad that all of our enhancements to font-lock are getting nullified by these problems. :-( -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

2 participants
1 comments

Re: Text properties slow down XEmacs 26 years, 2 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> I think the code would be more complex if font-lock > Hrvoje> attempted to do the merging/breaking by itself, but I > Hrvoje> might be wrong. It would certainly be faster that way... > > Given that we implement text properties in terms of extents, I don't > see a speed gain The speed gain is pretty obvious, once you think about it. Font-lock does specific things in a buffer, using text properties. However, text properties interface is not optimized for speed, but for FSF compatibility and whatnot. Jan has demonstrated how overlapping extents can simplify stuff that looks very complex with textprops. It remains to be seen about the complexity increase. > Hrvoje> My point was that the "native" balanced-tree > Hrvoje> implementation of text properties is bound to be faster > Hrvoje> than emulating them with extents. Perhaps I am wrong on > Hrvoje> that one, too. I would certainly *like* to be wrong on > Hrvoje> that one. > > The way the text properties interface is defined, I really don't see > them as anything but a restriction of the extent interface. Yes, and this restriction allows for optimization, doesn't it? For example, their text properties can't overlap. > In the end, for redisplay we _must_ update an extent when we change > a text property, for at least a significant fraction of the uses of > text properties. We may as well implement the character ranges > implicit in a balanced-tree implementation of text properties as > extents, and get that update "for free". No? I don't know. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Suburbia is where the developer bulldozes out the trees, then names the streets after them. -- Bill Vaughn

1 participants
0 comments

Re: Egcs flaming rubble 26 years, 2 months

Andreas Jaeger

>>>>> P E Jareth Hein writes: > I just tried to build 'Irish' with egcs-1.1b (which reports itself as > egcs-2.91.57) and got a flaming crash whilst trying to dump. Memory > fragmentation was so bad I can't tell where it went boom... Anyone > else with either success or failure reports? (I'm running > Linux-x86-2.1.105, binutils-2.9.1.0.4, ldd 1.9.9). I've reported at the end of July the problem to the egcs folks but didn't get an answer (but didn't really expect one since my report was much to vague). At that time I used egcs-2.91.51 19980714 to compile XEmacs-21.0-pre7 on my system (Linux 2.1.108 on i486 with glibc 2.0.94). With -O3 and -O1 I got the following failure: EMACSBOOTSTRAPLOADPATH="/mnt/xemacs/cvs-sources/xemacs-20/src/../lisp/:/mnt/xemacs/build-test" \ ./temacs -batch -l /mnt/xemacs/cvs-sources/xemacs-20/src/../lisp/update-elc.el Fatal error: assertion failed, file /mnt/xemacs/cvs-sources/xemacs-20/src/bufslots.h, line 36, abort() Compiling with older egcs versions didn't show that bug. After some more investigating I think the bug is somehow related to XEmacs's use of --use-union-type. Compiling with --use-union-type I manage to compile a working XEmacs 21.0 pre release. I haven't checked if current egcs and current XEmacs 21.0 compile cleanly with --use-union-type and the rest of the flags I normaly use. Btw. I just build the current XEmacs version with egcs 1.1 and it works for me (I've appended my installation file). I do think that egcs is somehow broken but don't have enough time to find out if this is true and to localize the bug. :-( Andreas uname -a: Linux arthur 2.1.113 #115 Tue Aug 25 10:10:49 CEST 1998 i486 unknown /mnt/xemacs/cvs-sources/xemacs-20/configure '--compiler=/opt/egcs/bin/gcc' '--cflags=-pipe -O3 -fno-exceptions -g -Wall -Wno-switch' '--prefix=/usr' '--package-path=~/.xemacs:/usr/lib/xemacs/packages:/usr/lib/xemacs/mule-packages' '--extra-verbose=no' '--with-site-lisp' '--const-is-losing=no' '--srcdir=/mnt/xemacs/cvs-sources/xemacs-20' '--with-gnu-make' '--with-database=no' '--error-checking=none' '--debug=no' '--mail-locking=flock' '--with-gpm=no' '--with-offix=no' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=athena' '--with-mule' XEmacs 21.0 "Norwegian" configured for `i486-pc-linux'. Where should the build process find the source code? /mnt/xemacs/cvs-sources/xemacs-20 What installation prefix should install use? /usr What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? /opt/egcs/bin/gcc -pipe -O3 -fno-exceptions -g -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "flock" for locking mail spool files. Using Lisp_Objects with minimal tagbits. -- Andreas Jaeger aj(a)arthur.rhein-neckar.de jaeger(a)informatik.uni-kl.de for pgp-key finger ajaeger(a)aixd1.rhrk.uni-kl.de

1 participants
0 comments

Re: [Success + quirks] 21.0 "Irish Goat" XEmacs Lucid on mips-sgi-irix6.3 26 years, 2 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > That appears to be due to my screwup, sorry. The release should be > consistent, at least before the next lisp package update. I am worried by this. there should be an package-get-base.el in the packages dir on the ftp site that is up to date always. All of our package tools are based on it. Would it be possible to have it created automatically. As far as I (and I guess a lot 21.0 users) am concerned lisp package updates that are not in package-get-base.el do not exists. If it is to too difficult for you to keep the two in sync then this counts as a major (IMHO release critical) bug. Just my 2 rappen Jan

1 participants
0 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 September 1998