September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Mule performance penalty 26 years, 2 months

Martin Buchholz

Hrvoje had trouble believing that the Mule penalty is only 30%. Obviously it depends on what you're doing. There will be places in the sources where switching from non-mule to mule will change an order-N algorithm to an order-N*N algorithm. I fixed such an algorithm in casefiddle.c. I am sure there are others. It is quite likely that using a fixed-width internal representation for characters instead of the current variable-width one is the right long-term strategy. Here are some benchmark results: pentiumpro pgcc -mcpu=pentiumpro -march=pentiumpro -O6 -fno-risc -fno-peep-spills -fno-omit-frame-pointer -fno-exceptions bytecomp font-lock --------------------------------------- Latin-1 42.8 40.3 Mule 75.5 43.7 Latin-1-M 31.4 40.5 Mule-M 38.4 41.6 Ultrasparc, Sun cc -fast -xO5 bytecomp font-lock --------------------------------------- Latin-1 31.0 30.9 Mule 51.8 32.5 Latin-1-M 21.7 31.2 Mule-M 25.9 34.3 Ultrasparc, egcs -O3 -mcpu=ultrasparc bytecomp font-lock --------------------------------------- Latin-1 31.7 26.5 Mule 55.5 28.0 Latin-1-M 22.0 25.7 Mule-M 25.7 27.5 The bytecomp benchmark is byte-compiling simple.el 20 times. The font-lock benchmark is font-lock-fontify-buffer-ing redisplay.c 3 times. The -M suffix means `hacked by Martin'. Smaller numbers are better. Only relative values count. So there may be a significant Mule performance penalty, or maybe not, depending on what you use xemacs for. There are some interesting conclusions from the above: - Sun cc wins on some benchmarks, egcs on others. - The changes I have made to speed up bytecomp actually slow down font-lock a little, but only when using Sun cc (??). It is fortuitous that this accidental change worked this way, since we ought to be targeting x86 and egcs as the architecture and compiler that more of our users will be using. - Benchmarking is hard. I've been concentrating lately on speeding up the bytecomp benchmark, since it is one of the purest tests of the lisp engine. Martin

1 participants
0 comments

Re: [Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 26 years, 2 months

Karl M. Hegbloom

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> wmperry(a)aventail.com (William M. Perry) writes: >> But it's perfectly acceptable to use ascii characters as >> accelerators. Hrvoje> I'm not sure I really like that idea of using a-z Hrvoje> characters when digits are exhausted. Also, I remember Hrvoje> other problems with a large number of choices, such as Hrvoje> being unable to scroll the choices buffer. I agree with Hrvoje here. I think 10 is enough, and for more than that, the standard minibuffer/completion->list-mode ought to be used. It's a better interface for a larger number of choices, since you can move around with incremental search, and it scrolls.

1 participants
0 comments

Re: [Russ Allbery <rra@stanford.edu>] Re: Status of pcl-cvs development? 26 years, 2 months

Karl M. Hegbloom

>>>>> "Darryl" == Darryl Okahata <darrylo(a)sr.hp.com> writes: Darryl> I prefer cvs.el because, unlike pcl-cvs, you don't have to Darryl> do a "cvs update" to get status information. The new `pcl-cvs' has `M-x cvs-examine' and `M-x cvs-status'.

1 participants
0 comments

Indirect buffers multiple-change fix 26 years, 2 months

Hrvoje Niksic

The multiple change stuff has an incredible way of complexifying and buggifying the code in insdel.c in subtle and not-so-subtle ways. For example, the indirect buffers code iterated signal_after_change() over all the indirect buffers; however, this caused a corruption of multiple-change structures followed by a crash which Karl reported. I hope this patch fixes the problem. I'm not sure I got it 100% right, but it seems to fix the crash. People who understand insdel.c, please keep your eyes open (Ben?). Karl, can you confirm that the crash is now gone? 1998-09-09 Hrvoje Niksic <hniksic(a)srce.hr> * insdel.c (signal_after_change): Add return value. (buffer_insert_string_1): Use it. (buffer_delete_range): Ditto. (buffer_replace_char): Ditto. (cancel_multiple_change): Map the indirect buffers. --- src/insdel.c.orig Wed Sep 9 23:35:34 1998 +++ src/insdel.c Wed Sep 9 23:41:57 1998 ＠＠ -1986,7 +1986,7 ＠＠ buf->changes->newline_was_deleted = 0; } -static void +static int signal_after_change (struct buffer *buf, Bufpos start, Bufpos orig_end, Bufpos new_end); ＠＠ -2012,11 +2012,17 ＠＠ if (buf->text->changes->mc_begin != 0 && buf->text->changes->mc_begin_signaled) { + struct buffer *mbuf; + Lisp_Object bufcons; Bufpos real_mc_begin = buf->text->changes->mc_begin; buf->text->changes->mc_begin = 0; - signal_after_change (buf, real_mc_begin, buf->text->changes->mc_orig_end, - buf->text->changes->mc_new_end); + /* #### Is this correct? */ + MAP_INDIRECT_BUFFERS (buf, mbuf, bufcons) + { + signal_after_change (buf, real_mc_begin, buf->text->changes->mc_orig_end, + buf->text->changes->mc_new_end); + } } else { ＠＠ -2216,9 +2222,12 ＠＠ START is the bufpos of the start of the changed text. ORIG_END is the bufpos of the end of the before-changed text. NEW_END is the bufpos of the end of the after-changed text. - */ -static void + Non-zero return value means that hooks are postponed until end of + multiple change. +*/ + +static int signal_after_change (struct buffer *buf, Bufpos start, Bufpos orig_end, Bufpos new_end) { ＠＠ -2240,7 +2249,7 ＠＠ assert (orig_end >= buf->text->changes->mc_begin && orig_end <= buf->text->changes->mc_new_end); buf->text->changes->mc_new_end += new_end - orig_end; - return; /* after-change-functions signalled when all changes done */ + return 1; /* after-change-functions signalled when all changes done */ } if (!NILP (symbol_value_in_buffer (Qafter_change_functions, buffer)) ＠＠ -2266,6 +2275,7 ＠＠ report_extent_modification (buffer, start, new_end, &inside_change_hook, 1); } + return 0; } /* Call this if you're about to change the region of BUFFER from START ＠＠ -2533,7 +2543,8 ＠＠ MAP_INDIRECT_BUFFERS (buf, mbuf, bufcons) { - signal_after_change (mbuf, pos, pos, pos + cclen); + if (signal_after_change (mbuf, pos, pos, pos + cclen)) + break; } UNGCPRO; ＠＠ -2845,7 +2856,8 ＠＠ MAP_INDIRECT_BUFFERS (buf, mbuf, bufcons) { - signal_after_change (mbuf, from, to, from); + if (signal_after_change (mbuf, from, to, from)) + break; } } ＠＠ -2918,7 +2930,8 ＠＠ memcpy (BUF_BYTE_ADDRESS (buf, pos), newstr, newlen); MAP_INDIRECT_BUFFERS (buf, mbuf, bufcons) { - signal_after_change (mbuf, pos, pos + 1, pos + 1); + if (signal_after_change (mbuf, pos, pos + 1, pos + 1)) + break; } /* We do not have to adjust the Mule data; we just replaced a -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Lost in Static 18 / And the storm is closing in now

1 participants
0 comments

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

Karl M. Hegbloom

I recently sent a query to the `gpm' mailing list concerning the `suspend-emacs' bug when configuring `--with-gpm' on Linux. Here is the letter and the response I recieved.

1 participants
0 comments

Re: [Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 26 years, 2 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > > > > > We should probably do a similar patch for the XEmacs version > > > > > of custom... I don't have the latest source right now > > > > > though... just a heads up. > > > > > > > > XEmacs already has a hardcoded limit of 10. > > > > > > This should be customizable. Hardcoded limits bad! > > > > There are only ten digits. > > But it's perfectly acceptable to use ascii characters as > accelerators. I'm not sure I really like that idea of using a-z characters when digits are exhausted. Also, I remember other problems with a large number of choices, such as being unable to scroll the choices buffer. > I wish the widget library would do some whizzy tricks and try to > match the accelerators to the first character of the string, and if > it's been used, use the next, etc. If all of them are used, use the > next available one, or something like that. Yes, that would be kind of cool. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth

1 participants
0 comments

Re: [Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 26 years, 2 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > > > > >> Perhaps we should add some upper limit to the # of items in a > > > >> menu before widget-menu-minibuffer-flag is ignored and we > > > >> prompt in the minibuffer (via completing-read) regardless? > > > > > > > We should probably do a similar patch for the XEmacs version of custom... I > > > > don't have the latest source right now though... just a heads up. > > > > > > XEmacs already has a hardcoded limit of 10. > > > > This should be customizable. Hardcoded limits bad! > > There are only ten digits. But it's perfectly acceptable to use ascii characters as accelerators. I wish the widget library would do some whizzy tricks and try to match the accelerators to the first character of the string, and if it's been used, use the next, etc. If all of them are used, use the next available one, or something like that. -Bill P.

1 participants
0 comments

Re: [Russ Allbery <rra@stanford.edu>] Re: Status of pcl-cvs development? 26 years, 2 months

Greg Klanderman

>>>>> "Hannu" == Hannu Koivisto <azure(a)iki.fi> writes: Hannu> Hannu> greg(a)alphatech.com (Greg Klanderman) writes: Hannu> | I too prefer pcl-cvs. Hannu> Hannu> This is what I thought would be the case for most CVS+Emacs Hannu> users. Thanks for the comments, you and Russ. I have been toying Hannu> with an idea to make a sort of a VC-replacement-layer for Hannu> pcl-cvs so that you could use the same functionality from "two Hannu> views", that is, via VC-based interface from buffers with the Hannu> current buffer/file being the default target of operation and Hannu> from pcl-cvs' traditional UI. I'll see if I can get anything Hannu> usable out of this idea. I imagine you should be able to use both pcl-cvs and either cvs.el or vc.el simultaneously as things are now. There's also a pcl-cvs-buffer.el included with 2.0b2 which gives buffer based cvs operation, though the timestamp indicates it has not been touched in nearly 6 years and I have never tried it. Hannu> | I'm currently synching our (XEmacs) version Hannu> | with Greg Woods' pcl-cvs 2.0b2 and adding several features. This will Hannu> Hannu> I hope your additions are usable also with Emacs. Yup, except for the font stuff in pcl-cvs-xemacs.el. Hannu> | Eventually I hope to get it working on NT too, though I do not Hannu> | actually use NT so I'll need some help there. Hannu> Hannu> I may be able to do testing at least. Assuming that I re-install Hannu> NT -- I swore I never touch NT again, but I guess I have to, if Hannu> not for other reasons, then simply to be able to maintain and Hannu> test my emacs configuration's NT support which some people Hannu> depend on :) Hannu> Hannu> //Hannu

1 participants
0 comments

Re: [Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 26 years, 2 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > > >> Perhaps we should add some upper limit to the # of items in a > > >> menu before widget-menu-minibuffer-flag is ignored and we > > >> prompt in the minibuffer (via completing-read) regardless? > > > > > We should probably do a similar patch for the XEmacs version of custom... I > > > don't have the latest source right now though... just a heads up. > > > > XEmacs already has a hardcoded limit of 10. > > This should be customizable. Hardcoded limits bad! There are only ten digits. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Those who like sausages, laws, and standards are well advised not to learn how they are made.

1 participants
0 comments

Re: Need internal help please (dynamic loading support) 26 years, 2 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > "J. Kean Johnston" <jkj(a)sco.com> writes: > > > I would like to enlist the help of an XEmacs internals guru to get > > me over these hurdles, if you think this would be a worthwhile > > exercise. I already have things set up such that compiling modules > > is trivial (and will work the same way on all platforms that support > > dlopen()). > > Note that you can achieve greater portability by using Bill's stuff in > sysdll.c. > > I'll try to answer some of your questions. > > > a) Getting DOC strings for variables defined correctly. When the .so > > is loaded in, a special function is called which does the moral > > equivalent of DEFSUBR() or DEFVAR_LISP() et al. I can see the > > variables defined but I dont know how to go about making the doc > > string visible. > > The doc string is a symbol property `variable-documentation'. It can > be either a string, or a character position in the DOC file. XEmacs > itself gets the docstrings done before the dumping; look for > `make-docfile' and friends. I was thinking of having a stub .el file be written out at build time that would just load the foo.ell file and stick the function documentation strings in brute force wise. This would make it so no hacking of `load' would need to happen - it would just find the stub .el file, which would do all the loading of the DLL, etc. Another option is to have the module do it after it calls DEFSUBR and friends. Stallman favors this approach. > > b) When i DEFSUBR() a function that was declared in the .so, and try > > to execute it, I get a SIGSEGV in Fcommanp when it calls > > SUBRP(fun). > > I'm not sure why that happens. Can you trace exactly where the segv > happens? did you compile --gung-ho? I seem to remember minimal tag bits being a requirement for the dll stuff to work. -bill p.

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