Re: Does VC work under EFS for 20.4
26 years, 4 months
Jan Vroonhof
Jan Vroonhof
"Yusuf Goolamabbas" <yusufg(a)huge.net> writes:
> Hi, If I do C-x v v for a file opened via EFS on a remote machine. It
> always fails and the output I get (assuming the file is called test)
> The file however exists on the remote server
>
> test,v <-- test
> ci: test: No such file or directory
>
> Is there any obvious thing I might have missed ?
Yes. C-x v v calls the RCS ci program and that obviously won't work
over ftp.
Jan
- 1 participants
- 0 comments
Widgets in buffers and subwindows patch
26 years, 4 months
Andy Piper
Andy Piper
This is largely the patch I intend to apply to 21.2.when-the-dust-has-settled
Now is the time to veto ;)
The patch provides subwindow support and native support for things like
combo boxes, buttons etc in a buffer. The X side has not had the platform
specific stuff implemented yet.
I'm happy with the implementation. I am less convinced about some of the
api which reuses and extends the menu button and glyph api's. Feedback
welcome.
Attached is a screenshot
andy
1998-12-06 Andy Piper <andy(a)xemacs.org>
* glyphs-msw.c (vars_of_glyphs_mswindows): provide widget types
here rather than in glyphs-widget - do this because we only want
to provide what is really available.
* glyphs.c (Fimage_instance_property): new function to get the
properties of image instances. wires through to console specific
methods and then to widget specific methods.
(Fset_image_instance_property): ditto but for setting widget properties.
(check_valid_face): make extern so that it can be used elsewhere.
* glyphs-widget.c (widget_property): new function. gets the
properties of widgets in general and wires the function through to
widget specific ones.
(widget_set_property): ditto but for setting widget properties.
* glyphs-msw.c (mswindows_combo_instantiate): Add functionality to
add items to the list. Play with window styles a bit to get the
desired effect.
(mswindows_widget_property): break out specific widget properties.
(mswindows_button_property): new function. gets the checked state
of a button.
(mswindows_combo_property): new function. gets the current
selection in the combo box.
(mswindows_widget_set_property): new function. sets specific
properties of specific widgets.
* glyphs-widget.c (check_valid_item_list): new function. check
that items for a combo-box are just a list of strings.
(combo_validate): new function. check there is an item list.
(widget_instantiate_1): new function. renamed from
widget_instantiate so that we can do slightly different things for
other widgets.
(widget_instantiate): call widget_instantiate_1.
(combo_instantiate): new function to instantiate combo boxes,
defaults height to the pixel height of the number of items in the
box.
(syms_of_glyphs_widget): move widget keywords here.
(image_instantiator_format_create_glyphs_widget): use new combo
functions.
1998-12-04 Andy Piper <andy(a)xemacs.org>
* event-msw.c (mswindows_wnd_proc): mule-ize.
* glyphs.c (pixmap_to_lisp_data): mule-ize.
* glyphs-msw.c (extract_xpm_color_names): mule-ize.
(resource_name_to_resource): ditto.
(mswindows_resource_instantiate): ditto.
(mswindows_widget_instantiate): ditto.
(mswindows_widget_set_property): ditto.
* redisplay-output.c (redisplay_output_subwindow): don't show
subwindows if they are obscured at the edge of the frame, emacs
gets into some sort of redisplay loop otherwise.
* gui.h: prototype gui_item_selected_p.
* gui.c (gui_item_selected_p): new function to determine the
selected state of a gui_item.
* frame.h (struct frame): add subwindows_changed flag.
* redisplay.c (redisplay_frame): call update_frame_subwindows ().
* glyphs.c (update_subwindow): new function to update a
subwindow's state.
(update_frame_subwindows): new function to update all the
subwindows on a frame.
* console.h (struct console_methods): add update_subwindow.
* glyphs-msw.c (mswindows_widget_property): return selected state
for selected property.
(mswindows_update_subwindow): new function. updates widget glyphs
in redisplay as per menubars or toolbars e.g. selected state.
(console_type_create_glyphs_mswindows): add update_subwindow.
1998-12-03 Andy Piper <andy(a)xemacs.org>
* console-tty.c (syms_of_console_tty): MULE -> FILE_CODING since
tty coding system things are such.
* sound.el (sound-load-list): name changed from sound-load-alist.
(sound-extension-list): name changed from sound-ext-list.
(load-default-sounds): use new names.
(load-sound-file): use new names.
* glyphs-widget.c (widget_face_font_info): new function for
pulling out height and width metrics for a widget's face.
(widget_text_to_pixel_conversion): calculate pixel sizes of text
for widgets.
* event-msw.c (mswindows_drain_windows_queue): translate messages
that are destined for subwindows. This makes edit fields interact
with the keyboard correctly.
nuke warnings by #ifndef'ing out stuff not required by msg select().
* glyphs.h (INITIALIZE_IMAGE_INSTANTIATOR_FORMAT_NO_SYM): new
macro defining the iiforma without the symbol required by widget.
(INITIALIZE_IMAGE_INSTANTIATOR_FORMAT): use it.
* general.c (syms_of_general): add Qwidget, Qselected.
* faces.c (complex_vars_of_faces): add widget face inheriting from
gui-element face.
1998-11-09 Andy Piper <andy(a)xemacs.org>
* window.h (struct window): add a cache of subwindows on a
per-window basis.
* window.c (mark_window): mark the subwindow_instance_cache.
(allocate_window): initialise the subwindow instance_cache.
* toolbar-x.c (x_output_toolbar): call redisplay_clear_region
instead of the devmeth.
(x_clear_toolbar): ditto.
* redisplay-x.c (x_output_display_block): call
redisplay_output_subwindow for subwindows and widgets.
* redisplay-tty.c (tty_output_display_block): add IMAGE_WIDGET to
types to do nothing for.
* lisp.h: declare new widget/subwindow symbols.
* glyphs.c (image_instantiate): cache subwindows on a per-window
basis.
(subwindow_possible_dest_types): new function for subwindow dest
types.
(subwindow_instantiate): generic instantiation of a
subwindow. specialised by device multi-methods.
(Fsubwindowp): moved from glyphs-x.c. adapted for glyph-based
subwindows.
(Fimage_instance_subwindow_id): ditto.
(Fresize_subwindow): ditto.
(Fforce_subwindow_map): ditto.
* glyphs-x.c (x_print_image_instance): remove subwindow
stuff. Handled genrically in glyphs.c.
(x_image_instance_equal): ditto.
(x_image_instance_hash): ditto.
(x_finalize_image_instance): delete subwindows when required.
(mark_subwindow) (print_subwindow) (finalize_subwindow)
(subwindow_hash) (Fmake_subwindow): deleted because of new,
glyph-based, subwindow implementation.
(Fsubwindow_height) (Fsubwindow_width) (Fsubwindow_xid): aliased
in glyphs.el
(Fsubwindowp) (Fresize_subwindow) (Fforce_subwindow_map): moved to
glyphs.c.
(x_unmap_subwindow): new function to unmap X subwindows.
(x_map_subwindow): new function to map X subwindows.
(x_subwindow_instantiate): new function to instantiate X
subwindows.
(x_resize_subwindow): new function to resize X subwindows.
(console_type_create_glyphs_x): add subwindow functions.
(image_instantiator_format_create_glyphs_x): add device
multi-methods for xpm, xbm and subwindow.
* glyphs.el (subwindow-xid): old alias for new subwindow functions.
(subwindow-width): ditto.
(subwindow-height): ditto.
* glyphs-msw.c (mswindows_widget_instantiate): new function for
generally instantiating ms subwindows. Used by
mswindows_*_instantiate.
(mswindows_edit_instantiate): instantiate an edit field on a
mswindows frame.
1998-11-04 Andy Piper <andy(a)xemacs.org>
* symsinit.h: declare new functions.
* redisplay.h: declare new functions.
* redisplay-x.c (x_output_display_block): call
redisplay_clear_region rather than x_clear_region.
(x_output_string): ditto.
(x_output_pixmap): ditto.
(x_clear_to_window_end): ditto.
(x_output_eol_cursor): ditto.
(x_clear_region): only do X specific things. other duties handled
in redisplay_clear_region.
* redisplay-tty.c (tty_clear_region): do tty specific things - some
duties moved to redisplay_clear_region.
* redisplay-output.c (clear_left_border): use
redisplay_clear_region instead of device method.
(clear_right_border): ditto.
(output_display_line): ditto.
(redisplay_output_subwindow): ditto.
(redisplay_clear_top_of_window): ditto.
(redisplay_clear_region): perform duties previously handled by
device methods. call the appropriate device method at the
end. unmap subwindows if necessary.
* redisplay-msw.c (mswindows_output_string): use
redisplay_clear_region instead of mswindows_clear_region.
(mswindows_clear_to_window_end): ditto.
(mswindows_output_display_block): output subwindows when required.
(mswindows_clear_region): only do mswindows specific things,
everything else is now handled in redisplay_clear_region.
* gui.h: add item id hash defines and declare function prototypes.
* gui.c (mark_gui_item): new function for marking gui_items.
(gui_item_hash): generic hash function for generating command ids
for gui_items.
* gui-msw.c: new file.
(mswindows_handle_gui_wm_command): new function to handle widget
callbacks.
* glyphs.h (MAYBE_IIFORMAT_DEVMETH): new function for device
multi-methods.
(IIFORMAT_HAS_SHARED_METHOD): ditto.
(DEFINE_DEVICE_IIFORMAT): ditto.
(INITIALIZE_DEVICE_IIFORMAT): ditto.
(struct Lisp_Image_Instance): add widget and subwindow data plus
appropriate access functions.
* glyphs.c (decode_device_ii_format): new function for decoding
image instantiator functions based on a device type as well as an
image format.
(decode_image_instantiator_format): just call
decode_device_ii_format with nil device.
(add_entry_to_device_ii_format_list): new function for per device
method instances.
(add_entry_to_image_instantiator_format_list): just call
add_entry_to_device_ii_format_list with nil device.
(check_valid_vector): new function.
(instantiate_image_instantiator): instantiate using per-format
method and then per-format-per-device method (device
multi-methods). signal an error if neither is possible.
(mark_image_instance): cope with subwindows and widgets.
(print_image_instance): ditto.
(image_instance_equal): ditto.
(image_instance_hash): ditto.
(allocate_glyph): ditto.
(glyph_width): ditto.
(glyph_height_internal): ditto.
(xpm_instantiate): removed because of device multi-methods.
(mark_subwindow_cachels): new cachel functions for caching
instantiated subwindows on a per-frame basis. mostly copied from
glyph cachel functions.
(update_subwindow_cachel_data): ditto.
(add_subwindow_cachel): ditto.
(get_subwindow_cachel_index): ditto.
(reset_subwindow_cachels): ditto.
(mark_subwindow_cachels_as_not_updated): ditto.
(unmap_subwindow): generic unmapping of subwindows based on cachel
data.
(map_subwindow): ditto.
(initialize_subwindow_image_instance): generic initialisation of
subwindow data.
(syms_of_glyphs): add widget keywords.
* glyphs-x.h (struct x_subwindow_data): convert Lisp_Subwindow to
x_subwindow_data.
1998-11-04 Andy Piper <andy(a)xemacs.org>
* glyphs-widget.c: new file for instantiating widget type glyphs.
(widget_possible_dest_types): new general dest type function for
widgets.
(widget_validate): ditto.
(initialize_widget_image_instance): ditto
(widget_instantiate): ditto. Sets up fg/bg, gui_item parsing
before handing on control to device multi-methods.
(syms_of_glyphs_widget): new function.
(image_instantiator_format_create_glyphs_widget): new function,
added placeholders for button, edit, combo, scrollbar
(vars_of_glyphs_widget): new function.
* glyphs-msw.h (WIDGET_INSTANCE_MSWINDOWS_HANDLE): new define for
storing window ids of widgets.
* glyphs-msw.c (mswindows_finalize_image_instance): cope with
deletion of widget and subwindow glyphs.
(mswindows_unmap_subwindow): new device function for unmapping
subwindows on a msw frame.
(mswindows_map_subwindow): ditto.
(mswindows_register_image_instance): register instantiated widgets
with the widget hastable.
(mswindows_button_instantiate): instantiate a button type widget
on an msw frame.
(mswindows_subwindow_instantiate): instanttiate a subwindow on a
mswindows frame.
(image_instantiator_format_create_glyphs_mswindows): add device
multi-methods for xbm, xpm, subwindow, edit and button.
* frame.h (struct frame): add subwindow_cachels dynarr for caching
information about subwindows visible on the current frame. used by
redisplay_clear_region to unmap subwindows as required.
* frame.c (mark_frame): mark subwindow_cachels.
(allocate_frame_core): instantiate subwindow_cachels.
* frame-msw.c (mswindows_init_frame_1): instntiate and mark the
widget hashtable.
* event-msw.c (mswindows_wnd_proc): add call to
mswindows_handle_gui_wm_command to handle widget callbacks.
* emacs.c (main_1): add calls to glyphs-widget initialisation
routines.
* console.h (struct console_methods): add
unmap/map_subwindow_method for use be redisplay_clear_region to
map and unmap subwindows. Remove xpm and xbm stuff - now dealt
with by image instantiator multi-methods. Add
resize_subwindow_method.
* console-stream.c (stream_clear_region): change signature to
match new generic clear region function.
* configure.in: add gui-msw.o to msw objects.
* Makefile.in.in: add glyphs-widget.o to list of objects.
* console-msw.h (struct mswindows_frame): add widget hashtable for
wiring command ids to callbacks.
---------------------------------------------------------------------------
" .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
Does VC work under EFS for 20.4
26 years, 4 months
Yusuf Goolamabbas
Yusuf Goolamabbas
Hi, If I do C-x v v for a file opened via EFS on a remote machine. It
always fails and the output I get (assuming the file is called test)
The file however exists on the remote server
test,v <-- test
ci: test: No such file or directory
Is there any obvious thing I might have missed ?
Regards, Yusuf
--
Yusuf Goolamabbas
yusufg(a)huge.net
- 1 participants
- 0 comments
Re: &rest and &optional in compiled function arglists
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Martin Buchholz <martin(a)xemacs.org> writes:
> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
>
> >> LIST_LOOP_3 itself is pretty cheap.
>
> Hrvoje> Hmm, yes. It bothers my esthetic soul to know that every time a
> Hrvoje> function is called its arglist is parsed in vain search of
> Hrvoje> `&optional', `&rest', and stuff. It somehow doesn't "feel right".
> Hrvoje> Obviously, the yearnings of my soul needn't have anything to with the
> Hrvoje> actual speed of the code. :-)
>
> Truly, my soul has also agonized over this question.
>
> The object-oriented way would be to have many different
> compiled-function object types, each of which has a different
> argument-parsing `method'.
I think that would be over-engineering. A Lisp_Object pointer and
three integers might work out better in this case.
- 2 participants
- 1 comments
Re: xemacs-21.2.5
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Martin Buchholz <martin(a)xemacs.org> writes:
> This is a `robustness' release. Circular lists are much less likely
> to freeze up your xemacs. Some illegal constructs in lisp or C code
> that used to be ignored are now tightened up,
Yes! It helped me catch a bug in htmlize.el. This used to run
without signaling an error:
(defvar htmlize-face-hash (make-hash-table :type 'eq))
In case it's not obvious, `:type' should really be `:test'. It wasn't
at all obvious to me.
> hash-table-tests.el: 8554 of 8554 (100%) tests successful.
> Testing /home/martin/x/dev/tests/automated/lisp-tests.el...
> lisp-tests.el: 3188 of 3188 (100%) tests successful.
> Testing /home/martin/x/dev/tests/automated/database-tests.el...
> database-tests.el: 20 of 20 (100%) tests successful.
> Testing /home/martin/x/dev/tests/automated/byte-compiler-tests.el...
> byte-compiler-tests.el: 50 of 50 (100%) tests successful.
> Done
> make[1]: Leaving directory `/home/martin/x/build/uop/src'
Could you add something like "all tests completed successfully", so we
can just glance at the last line and see if any investigation is
needed?
- 1 participants
- 0 comments
Re: &rest and &optional in compiled function arglists
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Martin Buchholz <martin(a)xemacs.org> writes:
> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
>
> Hrvoje> Martin Buchholz <martin(a)xemacs.org> writes:
> >> For best optimization, you would store the arglist directly inside the
> >> opaque object with the instructions for better locality of reference.
> >> Same with the constant vector.
>
> Hrvoje> Maybe. Maybe that's not really needed. For startes, I
> Hrvoje> would to see if the parameters looping (via LIST_LOOP_3)
> Hrvoje> takes a measurable amount of time for the average funcall
> Hrvoje> case. If yes, *any* optimization will do good. If not, we
> Hrvoje> needn't bother with locality.
>
> LIST_LOOP_3 itself is pretty cheap.
Hmm, yes. It bothers my esthetic soul to know that every time a
function is called its arglist is parsed in vain search of
`&optional', `&rest', and stuff. It somehow doesn't "feel right".
Obviously, the yearnings of my soul needn't have anything to with the
actual speed of the code. :-)
> Hrvoje> How much of the rest of what this URL describes have you
> Hrvoje> implemented? The specbind() stuff in the source looks
> Hrvoje> pretty much like the stuff Ben says we should have. The
> Hrvoje> same goes for the massaged byte-code stuff, as well as for
> Hrvoje> inlined unbind_to().
>
> The QUIT macro is no longer called.
> The arglist is only checked for proper-list-ness once.
> The other optimizations are not implemented.
Looking at the code, I cannot believe that the specbind() optimization
is not implemented. Also, I cannot believe that unbind_to()
optimization is not implemented.
> Perhaps, Hrvoje, you'd like to?
Why not?
> Keep in mind that the average function has one or two arguments.
> There is a danger that introducing too much machinery for argument
> parsing will actually be counter-productive. For example, we could
> store an arglist-parser function pointer in the compiled-function
> object, but the function call overhead is likely to be as high as
> parsing the arglist in the first place.
Not if the arglist is parsed only once, perhaps in
optimize_compiled_function(). All the other times, we have one
Lisp_Object pointer and two or three integers, and just use them. We
can even inline the call to Flist(), or whatever.
> Another win from reorganizing the arglist is simply saving on cons
> cells. (...)
Another good point, yes.
> Hrvoje> BTW, how do you obtain gprof output for a single benchmark?
>
> You build with -pg, run temacs, not xemacs, and run the benchmark in a
> loop a bazillion times.
Ugly ugly ugly... WIBN if gprof supported something like
gprof_start_recording() and gprof_stop_recording(), analogous to what
quantify has?
On Linux, where the source to gprof and libc are available, this might
even be implementable! Yay!
- 2 participants
- 1 comments
xemacs-21.2.5
26 years, 4 months
Martin Buchholz
Martin Buchholz
Anyone who wants to look at the (large) diffs for xemacs-21.2.5 can
find them at:
ftp://ftp.xemacs.org/pub/xemacs/beta/testing/marzilla.diff.bz2
ftp://ftp.xemacs.org/pub/xemacs/beta/testing/marzilla.diff-w.bz2
The diff is generated using diff -u, and is designed to be machine readable.
The diff-w is generated using diff -w -U8, and is designed to be human
readable.
Bughunters (i.e. Kyle) will want to look at bytecode.c, alloc.c and
elhash.c, since those files have been largely rewritten. There's
pretty much guaranteed to be a bug in there somewhere.
Here's some stuff I wrote earlier that I don't think made it to
this list:
This is a `performance' release. The lisp engine (especially under
Mule) and hash tables are significantly faster. See whether it feels
faster for you.
This is a `robustness' release. Circular lists are much less likely
to freeze up your xemacs. Some illegal constructs in lisp or C code
that used to be ignored are now tightened up, like
(setq foo)
which used to byte-compile. No longer.
This is also a `testing' release. I'd like folks to try running
make check
after building XEmacs. You should see stuff like this:
------------------------------------------------------------------------
(martin＠lasker) ~/x/build/uop $ make check
cd ./src && make check
make[1]: Entering directory `/home/martin/x/build/uop/src'
./xemacs -batch -l /home/martin/x/dev/src/../tests/automated/test-harness.el -f batch-test-emacs /home/martin/x/dev/src/../tests/automated/hash-table-tests.el /home/martin/x/dev/src/../tests/automated/lisp-tests.el /home/martin/x/dev/src/../tests/automated/database-tests.el /home/martin/x/dev/src/../tests/automated/byte-compiler-tests.el
Testing /home/martin/x/dev/tests/automated/hash-table-tests.el...
hash-table-tests.el: 8554 of 8554 (100%) tests successful.
Testing /home/martin/x/dev/tests/automated/lisp-tests.el...
lisp-tests.el: 3188 of 3188 (100%) tests successful.
Testing /home/martin/x/dev/tests/automated/database-tests.el...
database-tests.el: 20 of 20 (100%) tests successful.
Testing /home/martin/x/dev/tests/automated/byte-compiler-tests.el...
byte-compiler-tests.el: 50 of 50 (100%) tests successful.
Done
make[1]: Leaving directory `/home/martin/x/build/uop/src'
------------------------------------------------------------------------
This is also an `unstable' release, simply because of the huge volume
of changes. There will be bugs. Happy hunting! Keep around a copy of
21.2-b4 for a while for problem determination.
- 1 participants
- 0 comments
Re: &rest and &optional in compiled function arglists
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Martin Buchholz <martin(a)xemacs.org> writes:
> For best optimization, you would store the arglist directly inside the
> opaque object with the instructions for better locality of reference.
> Same with the constant vector.
Maybe. Maybe that's not really needed. For startes, I would to see
if the parameters looping (via LIST_LOOP_3) takes a measurable amount
of time for the average funcall case. If yes, *any* optimization will
do good. If not, we needn't bother with locality.
Since you carried this off to xemacs-beta, I might as well quote Ben
from <URL:http://www.666.com/xemacs/faster-elisp.html>:
1. The byte-compiled function's parameter list is stored in exactly
the format that the programmer entered it in, which is to say as a
Lisp list, complete with &optional and &rest keywords. This list
has to be parsed for every function invocation, which means that
for every element in a list, the element is checked to see whether
it's the &optional or &rest keywords, its surrounding cons cell is
checked to make sure that it is indeed a cons cell, the QUIT macro
is called, etc. What should be happening here is that the argument
list is parsed exactly once, at the time that the byte code is
loaded, and converted into a C array. The C array should be stored
as part of the byte-code object. The C array should also contain,
in addition to the symbols themselves, the number of required and
optional arguments. At function call time, the C array can be very
quickly retrieved and processed.
How much of the rest of what this URL describes have you implemented?
The specbind() stuff in the source looks pretty much like the stuff
Ben says we should have. The same goes for the massaged byte-code
stuff, as well as for inlined unbind_to().
> This will also speed up garbage collection. bytecode.c will get a
> little uglier, however.
>
> It won't buy as much as you'd like, though.
It depends on my value of "like". Making funcalls 5% or 10% faster is
not a bad thing.
> On second thought, the obvious way to exercise funcall is using
> mapc.
>
> Here's a gprof output for (mapc (lambda (x) (incf z x)) long-list):
>
> % cumulative self self total
> time seconds seconds calls ms/call ms/call name
> 35.3 226.20 226.20 300015011 0.00 0.00 execute_optimized_program <cycle 3> [6]
> 23.3 375.60 149.40 300013990 0.00 0.00 funcall_compiled_function <cycle 3> [7]
> 19.4 500.16 124.56 300364373 0.00 0.00 Ffuncall <cycle 3> [8]
According to this benchmark, quite a lot of time is spent in
funcall_compiled_function(). Building with quantify might be useful
here, to see what instructions take up what amount of time.
BTW, how do you obtain gprof output for a single benchmark?
> Of course, mapc and friends can be sped up by putting Ffuncall-style
> smarts into mapcar1(). But I don't see any way offhand of how to do
> this elegantly.
Perhaps by making them into a macro, similar to how SPECBIND was
handled? Admittedly, this is still rather ugly, but...
- 2 participants
- 1 comments
Re: &rest and &optional in compiled function arglists
26 years, 4 months
Martin Buchholz
Martin Buchholz
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
Hrvoje> Now that we have various optimizations, it looks a bit funny that
Hrvoje> compiled functions parse their arglist on every funcall. Shouldn't it
Hrvoje> be possible to have an ->optimized_arglist element in the compiled
Hrvoje> function, filled out by optimize_compiled_function() (or by something
Hrvoje> else)?
Hrvoje> The element could be a structure, like this:
Hrvoje> struct optimized_args {
Hrvoje> int argcount, optcount, restcount;
Hrvoje> Lisp_Object *argvector;
Hrvoje> }
Hrvoje> This would allow for the removal of LIST_LOOP_3 at
Hrvoje> funcall_compiled_function(). At a later date, the code could be
Hrvoje> easily expanded to cleanly process keyword arguments.
Hrvoje> Have you perhaps already tried that line of optimization and concluded
Hrvoje> it was not worth it? Or have you not thought of that?
I've actually done a fair amount of thinking about this.
Particularly painful from the point of view of performance is the fact
that almost no functions have &optional or &rest parameters.
Most functions have zero, one, or two ordinary parameters. Perhaps we
could have special cases for those.
For best optimization, you would store the arglist directly inside the
opaque object with the instructions for better locality of reference.
Same with the constant vector. This will also speed up garbage
collection. bytecode.c will get a little uglier, however.
It won't buy as much as you'd like, though.
Here is the head of gprof output for (byte-compile-file "simple.el") on Sun:
% cumulative self self total
time seconds seconds calls ms/call ms/call name
26.8 265.02 265.02 24293397 0.01 0.02 execute_optimized_program <cycle 3> [5]
9.0 353.63 88.61 _mcount (6644)
5.7 409.88 56.25 107146042 0.00 0.00 bufpos_to_bytind_func [21]
5.4 463.45 53.57 32144818 0.00 0.00 mark_object <cycle 2> [23]
4.6 508.51 45.06 172449465 0.00 0.00 set_buffer_point [25]
4.2 550.16 41.65 oldarc [26]
3.9 588.82 38.66 2042 18.93 19.33 decode_coding_iso2022 [30]
3.8 626.17 37.35 44511947 0.00 0.00 Ffuncall <cycle 3> [7]
2.7 652.96 26.79 24285878 0.00 0.00 funcall_compiled_function <cycle 3> [39]
2.6 678.27 25.31 83869017 0.00 0.00 readchar [22]
2.2 699.82 21.55 62705330 0.00 0.00 Fmemq [43]
1.6 715.51 15.69 5822540 0.00 0.02 buffer_insert_string_1 [9]
1.6 731.12 15.61 320510 0.05 0.24 skip_chars [15]
1.4 745.24 14.12 7610693 0.00 0.00 Fassq [54]
1.1 756.49 11.25 next [56]
1.0 766.47 9.98 4985 2.00 14.57 garbage_collect_1 <cycle 3> [16]
_mcount and oldarc are measurement overhead.
Here is gprof on Linux:
% cumulative self self total
time seconds seconds calls ms/call ms/call name
46.79 409.06 409.06 24295909 0.02 0.02 execute_optimized_program
9.25 489.94 80.88 22500420 0.00 0.00 mark_object
3.90 524.05 34.11 24288192 0.00 0.00 funcall_compiled_function
3.49 554.54 30.49 44373981 0.00 0.00 Ffuncall
2.94 580.28 25.74 62702820 0.00 0.00 Fmemq
2.58 602.86 22.58 928 24.33 24.33 sweep_conses
2.55 625.15 22.29 95129330 0.00 0.00 set_buffer_point
2.37 645.86 20.71 83653640 0.00 0.00 readchar
1.41 658.16 12.30 5822327 0.00 0.01 buffer_insert_string_1
1.21 668.72 10.56 7614031 0.00 0.00 Fassq
1.17 678.96 10.24 26409642 0.00 0.00 map_extents_bytind
0.92 686.97 8.01 29062131 0.00 0.00 find_symbol_value_1
0.91 694.94 7.97 928 8.59 8.60 compact_string_chars
0.86 702.43 7.49 3187928 0.00 0.01 read_atom_0
0.76 709.04 6.61 24361635 0.00 0.00 symbol_value_in_buffer
0.74 715.53 6.49 5824902 0.00 0.00 signal_after_change
0.70 721.65 6.12 5313527 0.00 0.01 read1
0.66 727.44 5.79 9362082 0.00 0.00 advance_plist_pointers
It seems that even if you make funcall_compiled_function infinitely
fast, this benchmark will only be 5-10% faster, at best.
Hmmmmmmmmmmmmmmmmmmmmmmmmm.
On second thought, the obvious way to exercise funcall is using
mapc.
Here's a gprof output for (mapc (lambda (x) (incf z x)) long-list):
% cumulative self self total
time seconds seconds calls ms/call ms/call name
35.3 226.20 226.20 300015011 0.00 0.00 execute_optimized_program <cycle 3> [6]
23.3 375.60 149.40 300013990 0.00 0.00 funcall_compiled_function <cycle 3> [7]
19.4 500.16 124.56 300364373 0.00 0.00 Ffuncall <cycle 3> [8]
12.2 578.34 78.18 _mcount (6644)
4.6 607.68 29.34 oldarc [14]
1.7 618.80 11.12 300288 0.04 0.04 mapcar1 <cycle 3> [19]
1.4 627.96 9.16 320473 0.03 0.03 Flength [21]
1.0 634.22 6.26 done [24]
0.4 636.56 2.34 3692039 0.00 0.00 mark_object <cycle 2> [29]
0.1 637.00 0.44 2425273 0.00 0.00 readchar [38]
0.0 637.32 0.32 1565358 0.00 0.00 put_char_table <cycle 3> [42]
0.0 637.59 0.27 882 0.31 0.35 decode_coding_no_conversion [43]
0.0 637.85 0.26 46702 0.01 0.01 mark_hash_table <cycle 2> [45]
0.0 638.08 0.23 3414 0.07 0.95 garbage_collect_1 <cycle 3> [26]
0.0 638.30 0.22 1891385 0.00 0.00 cmst_mapfun <cycle 3> [47]
0.0 638.52 0.22 183 1.20 1.20 compact_string_chars [46]
0.0 638.71 0.19 382545 0.00 0.00 map_over_other_charset <cycle 3> [50]
0.0 638.89 0.18 131826 0.00 0.01 read1 <cycle 3> [36]
Hmmmmmmmmmmmmmmmmmmmmmmmmmmm.
Better yet, if you want to measure pure Ffuncall, do (mapc #'identity long-list):
Sun:
% cumulative self self total
time seconds seconds calls ms/call ms/call name
60.2 325.03 325.03 600664277 0.00 0.00 Ffuncall <cycle 3> [5]
17.3 418.21 93.18 _mcount (6644)
7.1 456.57 38.36 oldarc [10]
5.2 484.42 27.85 600000160 0.00 0.00 Fidentity [13]
3.8 504.99 20.57 600284 0.03 0.03 mapcar1 <cycle 3> [14]
3.3 522.66 17.67 620458 0.03 0.03 Flength [16]
1.5 530.71 8.05 done [21]
0.5 533.21 2.50 3692036 0.00 0.00 mark_object <cycle 2> [27]
0.3 534.95 1.74 14960 0.12 0.13 execute_optimized_program <cycle 3> [29]
0.1 535.37 0.42 1565358 0.00 0.00 put_char_table <cycle 3> [39]
0.1 535.74 0.37 2425246 0.00 0.00 readchar [37]
0.1 536.09 0.35 882 0.40 0.42 decode_coding_no_conversion [42]
0.0 536.35 0.26 3414 0.08 1.00 garbage_collect_1 <cycle 3> [25]
0.0 536.57 0.22 46702 0.00 0.00 mark_hash_table <cycle 2> [45]
0.0 536.75 0.18 382545 0.00 0.00 map_over_other_charset <cycle 3> [50]
Linux:
% cumulative self self total
time seconds seconds calls ms/call ms/call name
70.43 55.82 55.82 120162804 0.00 0.00 Ffuncall
9.55 63.39 7.57 120169 0.06 0.06 mapcar1
6.12 68.24 4.85 120000057 0.00 0.00 Fidentity
5.41 72.53 4.29 137347 0.03 0.03 Flength
3.33 75.17 2.64 2315065 0.00 0.00 mark_object
0.44 75.52 0.35 148 2.36 2.36 compact_string_chars
0.40 75.84 0.32 2209869 0.00 0.00 readchar
0.35 76.12 0.28 9975 0.03 0.04 execute_optimized_program
0.34 76.39 0.27 148 1.82 1.82 sweep_symbols
0.32 76.64 0.25 32503 0.01 0.01 mark_hash_table
0.23 76.82 0.18 122237 0.00 0.00 hash_string
0.21 76.99 0.17 87471 0.00 0.00 oblookup
0.18 77.13 0.14 148 0.95 0.95 sweep_conses
0.15 77.25 0.12 148 0.81 0.81 sweep_strings
0.14 77.36 0.11 111560 0.00 0.01 read1
0.13 77.46 0.10 67448 0.00 0.00 read_atom_0
0.10 77.54 0.08 13203 0.01 0.01 re_match_2_internal
Of course, mapc and friends can be sped up by putting Ffuncall-style
smarts into mapcar1(). But I don't see any way offhand of how to do
this elegantly.
Martin
P.S. Caveat benchmarker: gprof numbers are notoriously unreliable.
- 1 participants
- 0 comments
PUI impressions
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
> Hrvoje Niksic <hniksic(a)srce.hr> writes:
>
> > How do I use pui? I tried `M-x pui-list-packages', but it tried to
> > connect to ftp.xemacs.org and failed miserably because you can't do
[...]
This seems to work right in 21.2.5. The current working definition of
"right" is that it doesn't try to connect to ftp.xemacs.org right
away.
> Then pui-list-packages will never go remote. We added that
> especially for you.
Thanks. :-)
I'm now playing with pui, and I think I like the look. Here are some
problems:
* The button3 menu is misleading. It appears to operate on the item
under the point, as opposed to the item under the mouse. Could you
please fix that?
* C-h m doesn't print anything useful. This is a no-no -- `C-h m' is
/the/ advertised way to get help with unfamiliar Emacs modes. I
think you can safely remove the "useful keys" section and make `C-h
m' print that.
* I would like SPC and DEL to scroll forward, backward, but never
mind... :-)
* The SPC binding is horribly wasted; I expected it to print more info
about the package, such as installed-size, last-change-date, and the
like. Instead of that, it just dumped the author's name to the echo
area.
* How do I mark a package for deletion and/or delete it? I expected
`d' and `x' to do it (cf. dired), but I was unpleasantly surprised.
* I think you should set `truncate-lines' to t in PUI buffer.
* I think you need a name better than `ptui'. :-) How about
`pselect'?
* The `?' button should use `with-displaying-help-buffer', to be
compatible with the rest of XEmacs.
* How do I list package dependencies?
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"
- 1 participants
- 0 comments