Re: XEmacs 21.5 much slower remotely?

Adam Sjøgren writes: Well, the place to start is the Internals manual, the chapter on redisplay. It's not terribly detailed and somewhat out of date, but it gives an overview of how things work. Then look at src/redisplay*.c and related files. Profiling won't help much. You can see that the problem is the the same content gets redrawn over and over again. The question that needs to be answered is "why?" and I don't think profiling can answer that because redraws are event-driven. The question is what are the events that are causing redraws, and why are they so frequent? My hypothesis is based on the fact that redisplay can be "cancelled" or "aborted" (I forget the exact word used) if it detects that the display has changed since it started, somehow. This is *supposed* to be a reaction to X events initiated by the user, but what actually happens is that redisplay goes behind the toolkit's back to map and unmap windows, which generates events, which causes redisplay to abort. I'm pretty sure that this is what is causing the problem. There's some crufty code which tries to reognize events induced by redisplay itself, but it pretty clearly doesn't work. You might try putting a counter in places where such an "abort" can happen. Use the DEFVAR_INT macro to define it, then you can just do redisplay_abort_counter++ in those places, and check it from Lisp. For comparison, you could see if you can find (or build) a 21.1 XEmacs (21.4 won't do, it already has the cruft in redisplay). Of course it won't have Xft, but you can roughly compare the number of aborts. If my hypothesis is correct, the difference should be spectacular. You could also use xevent to capture the events going to the window and see what they are. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta