[xemacs-hg @ 2003-03-09 02:27:27 by ben] To: xemacs-patches@xemacs.org i.c: Sleep between calls to check for I/O, since these calls are non-blocking. behavior.el: Allow other keywords for forward compatibility. cl-macs.el: Rewrite to eliminate byte-compiler warning when `return' is used without `finally'. cmdloop.el: Avoid truncated error messages for `end-of-file' and the like. cmdloop.el: Avoid char-int error after syncing. files.el: Eliminate byte-compile warnings. printer.el: Fix line-width calculations. #### This used to work. Someone's changes (perhaps by Michael Sperber?) seem to have messed something up. simple.el: Use new clear-left-side functions to avoid messages ending up on the same line as other output. xemacs.mak: Add override for info/ as well when separate source/build dirs. xemacs.mak: Order sections in main build process and add comments. Add additional dependencies to try and prevent later steps from happening when failures in earlier steps have occurred. Makefile.in.in: Order sections in main build process and add comments. Add additional dependencies to try and prevent later steps from happening when failures in earlier steps have occurred. alloc.c: Don't arbitrarily clear Vconfigure_info_directory since it messes up separate build/source dirs. console.c, console.h, device-msw.c, device.c: Add accidentally omitted msprinter console and data descriptions. print.c, console-msw.c: Add clear-left-side functionality to help keep stdio/stderr output from separate sources on separate lines. Generalize the different kinds of debugging output. Add dpa(). profile.c: Add better docs on Unix/Windows differences. regex.c: Fix problems with rel-alloc compilation caused by previous patch. emacs.c: Seg fault rather than abort on Cygwin, since gdb doesn't trap aborts properly. console-gtk-impl.h, console-gtk.h, console-msw.h, console-x-impl.h, console-x.h, dialog-gtk.c, dialog-x.c, event-msw.c, frame-gtk.c, frame-x.c, frameslots.h, glyphs-gtk.c, glyphs-x.c, gui-gtk.c, gui-x.c, inline.c, menubar-gtk.c, menubar-msw.c, menubar-x.c, scrollbar-gtk.c, scrollbar-x.c, ui-gtk.c: Delete popup-data object. Delete menubar_data field from frames, since its usage is frame-specific. Delete menubar-msw.h, gui-x.h, gui-gtk.h. Clean up handling of lwlib callback data GCPRO'ing and add missing GCPRO recomputation in widget code.

--- a/src/profile.c	Sat Mar 08 22:52:26 2003 +0000
+++ b/src/profile.c	Sun Mar 09 02:27:46 2003 +0000
@@ -51,8 +51,15 @@
    The basic idea is simple.  We set a profiling timer using setitimer
    (ITIMER_PROF), which generates a SIGPROF every so often.  (This runs not
    in real time but rather when the process is executing or the system is
-   running on behalf of the process.) When the signal goes off, we see what
-   we're in, and add 1 to the count associated with that function.
+   running on behalf of the process -- at least, that is the case under
+   Unix.  Under MS Windows and Cygwin, there is no setitimer(), so we
+   simulate it using multimedia timers, which run in real time.  To make
+   the results a bit more realistic, we ignore ticks that go off while
+   blocking on an event wait.  Note that Cygwin does provide a simulation
+   of setitimer(), but it's in real time anyway, since Windows doesn't
+   provide a way to have process-time timers, and furthermore, it's broken,
+   so we don't use it.) When the signal goes off, we see what we're in, and
+   add 1 to the count associated with that function.
 
    It would be nice to use the Lisp allocation mechanism etc. to keep track
    of the profiling information (i.e. to use Lisp hash tables), but we
@@ -706,9 +713,12 @@
   DEFVAR_INT ("default-profiling-interval", &default_profiling_interval /*
 Default CPU time in microseconds between profiling sampling.
 Used when the argument to `start-profiling' is nil or omitted.
-Note that the time in question is CPU time (when the program is executing
-or the kernel is executing on behalf of the program) and not real time, and
-there is usually a machine-dependent limit on how small this value can be.
+Under Unix, the time in question is CPU time (when the program is executing
+or the kernel is executing on behalf of the program) and not real time.
+Under MS Windows and Cygwin, the time is real time, but time spent blocking
+while waiting for an event is ignored, to get more accurate results.
+Note that there is usually a machine-dependent limit on how small this
+value can be.
 */ );
   default_profiling_interval = 1000;