* Re: Speed difference in Gnus [not found] <87r7ap899o.fsf@xemacs.org> @ 2005-10-13 21:17 ` Reiner Steib [not found] ` <434EFD44.7030601@xemacs.org> 1 sibling, 0 replies; 22+ messages in thread From: Reiner Steib @ 2005-10-13 21:17 UTC (permalink / raw) Cc: xemacs-beta, Ding List On Thu, Oct 13 2005, Hrvoje Niksic wrote: > The speed difference between XEmacs and GNU Emacs is amazing, in that > GNU Emacs is significantly faster, at least for "heavy" usage such as > Gnus. Interesting. Which versions of (X)Emacs and Gnus did you test? > Entering a large summary buffer takes time proportional to the > *square* of the number of messages in the folder. (This is not a > wild guess, a friend has actually measured.) Time to enter a folder > of more than 3000 articles quickly degrades to minutes. > > For the longest time I believed this to be a result of XEmacs's > implementation of text properties on top of extents. I planned to > convert Gnus to use extents natively, in the hope that it would speed > up summary buffer generation. Then `M-RET' should be significantly faster, shouldn't it? ,----[ <f1> f gnus-group-quick-select-group RET ] | gnus-group-quick-select-group is an interactive compiled Lisp | function in `gnus-group.el'. | (gnus-group-quick-select-group &optional ALL) | | Select the current group "quickly". | This means that no highlighting or scoring will be performed. | If ALL (the prefix argument) is 0, don't even generate the summary | buffer. | | This might be useful if you want to toggle threading | before entering the group. `---- > But according to profiling, most of the time is spent in `insert', > at least once you discount excessive GC by increasing > gc-cons-theshold. I'm not sure what XEmacs is doing wrong here. I > suspect Mule is to blame, but I can't prove it. `C-u 0 M-RET' probably doesn't use insert so often. Is it comparable to `C-u 0 M-RET' in Emacs then? > Using FSF Emacs gave me an order-of-magnitude speedup when entering > large newsgroups and large mailing list folders. It's uncanny. Bye, Reiner. PS: Cc-ing ding. This might be interesting for Gnus developers. See http://thread.gmane.org/gmane.emacs.xemacs.beta/20690 for the whole thread. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <434EFD44.7030601@xemacs.org>]
[parent not found: <877jcgub0f.fsf@xemacs.org>]
[parent not found: <434F3897.3050007@xemacs.org>]
[parent not found: <873bn4tptq.fsf@xemacs.org>]
[parent not found: <87d5m89wuf.fsf@tleepslib.sk.tsukuba.ac.jp>]
[parent not found: <87y84nyuo0.fsf@mat.ucm.es>]
[parent not found: <873bmulscb.fsf@tleepslib.sk.tsukuba.ac.jp>]
[parent not found: <87pspypwzv.fsf@mat.ucm.es>]
[parent not found: <sluuli82.fsf@smtprelay.t-online.de>]
* Re: Speed difference in Gnus [not found] ` <sluuli82.fsf@smtprelay.t-online.de> @ 2005-10-24 16:52 ` Uwe Brauer 2005-10-24 18:24 ` David Kastrup 2005-10-24 21:00 ` Reiner Steib 0 siblings, 2 replies; 22+ messages in thread From: Uwe Brauer @ 2005-10-24 16:52 UTC (permalink / raw) Cc: ding >>>>> "APA" == Adrian Aichner <adrian@xemacs.org> writes: APA> Uwe Brauer <oub@mat.ucm.es> writes: [snip] APA> a* profile-command - Run COMMAND, profiling the APA> execution and displaying the results. Hello Adrian, Thanks this command worked fine, I did various tests, either having all my packages loaded or not, I attach the one, with all packages used. I looked for profile commands in gnus emacs, there is no per default, google did not really help, Could somebody of the gnu folks[1] please point me out how to profile a command in either gnu emacs 21 or 22. Thanks Uwe Brauer [1] thats why I post also to the gnus group ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-24 16:52 ` Uwe Brauer @ 2005-10-24 18:24 ` David Kastrup 2005-10-25 9:50 ` Uwe Brauer 2005-10-24 21:00 ` Reiner Steib 1 sibling, 1 reply; 22+ messages in thread From: David Kastrup @ 2005-10-24 18:24 UTC (permalink / raw) Cc: ding Uwe Brauer <oub@mat.ucm.es> writes: >>>>>> "APA" == Adrian Aichner <adrian@xemacs.org> writes: > > APA> Uwe Brauer <oub@mat.ucm.es> writes: > > [snip] > > > APA> a* profile-command - Run COMMAND, profiling the > APA> execution and displaying the results. > > Hello Adrian, > > Thanks this command worked fine, I did various tests, either having all > my packages loaded or not, I attach the one, with all packages used. > I looked for profile commands in gnus emacs, there is no per default, > google did not really help, > > Could somebody of the gnu folks[1] please point me out how to profile a > command in either gnu emacs 21 or 22. M-x elp-instrument-package RET gnus RET Do something M-x elp-results RET -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-24 18:24 ` David Kastrup @ 2005-10-25 9:50 ` Uwe Brauer 2005-10-25 10:48 ` David Kastrup 2005-10-25 17:50 ` Jesper Harder 0 siblings, 2 replies; 22+ messages in thread From: Uwe Brauer @ 2005-10-25 9:50 UTC (permalink / raw) Cc: xemacs-beta >>>>> "David" == David Kastrup <dak@gnu.org> writes: David> M-x elp-instrument-package RET gnus RET David> Do something David> M-x elp-results RET Thanks, this function also exists in xemacs (and I did not know about it), in any case the information is very aehm spare: for emacs-21 I obtain: --8<------------------------schnipp------------------------->8--- Function Name Call Count Elapsed Time Average Time ========================= ========== ============ ============ gnus-summary-copy-article 1 14.03726 14.03726 --8<------------------------schnapp------------------------->8--- for xemacs 21.4.17 I get --8<------------------------schnipp------------------------->8--- Function Name Call Count Elapsed Time Average Time ========================= ========== ============ ============ gnus-summary-copy-article 1 15.869385 15.869385 --8<------------------------schnapp------------------------->8--- However the profile-command of xemacs give me detailed information of the sort: --8<------------------------schnipp------------------------->8--- Function Name Ticks/Total %Usage Calls GC-Usage/ Total ===========================================/===== ====== ===== ========/======= (in garbage collection) 237/ 0 39.109 next-single-property-change 70/ 0 11.551 24664 get-text-property 33/ 0 5.446 29299 --8<------------------------schnapp------------------------->8--- Etc etc I tried to compile xemacs, profile package under emacs-21 without success. Does there exist any add-on package for more profiling details? Thanks Uwe Brauer ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-25 9:50 ` Uwe Brauer @ 2005-10-25 10:48 ` David Kastrup 2005-10-25 17:50 ` Jesper Harder 1 sibling, 0 replies; 22+ messages in thread From: David Kastrup @ 2005-10-25 10:48 UTC (permalink / raw) Cc: ding Uwe Brauer <oub@mat.ucm.es> writes: >>>>>> "David" == David Kastrup <dak@gnu.org> writes: > > David> M-x elp-instrument-package RET gnus RET > David> Do something > David> M-x elp-results RET > > Thanks, this function also exists in xemacs (and I did not know about > it), in any case > the information is very aehm spare: > for emacs-21 I obtain: > --8<------------------------schnipp------------------------->8--- > Function Name Call Count Elapsed Time Average Time > ========================= ========== ============ ============ > gnus-summary-copy-article 1 14.03726 14.03726 > --8<------------------------schnapp------------------------->8--- > for xemacs 21.4.17 I get > --8<------------------------schnipp------------------------->8--- > Function Name Call Count Elapsed Time Average Time > ========================= ========== ============ ============ > gnus-summary-copy-article 1 15.869385 15.869385 > --8<------------------------schnapp------------------------->8--- Well, you should instrument the package _after_ loading all relevant functions, or just the autoloads get instrumented. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-25 9:50 ` Uwe Brauer 2005-10-25 10:48 ` David Kastrup @ 2005-10-25 17:50 ` Jesper Harder 2005-10-25 22:07 ` David Kastrup 1 sibling, 1 reply; 22+ messages in thread From: Jesper Harder @ 2005-10-25 17:50 UTC (permalink / raw) Cc: ding Uwe Brauer <oub@mat.ucm.es> writes: >>>>>> "David" == David Kastrup <dak@gnu.org> writes: > > David> M-x elp-results RET > > Thanks, this function also exists in xemacs (and I did not know > about it), in any case the information is very aehm spare: You should probably also instrument the `nnml', `imap', `mm' and `mml' packages (and maybe some more depending on which operation you're benchmarking -- I don't recall). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-25 17:50 ` Jesper Harder @ 2005-10-25 22:07 ` David Kastrup 2005-10-26 9:32 ` Uwe Brauer 0 siblings, 1 reply; 22+ messages in thread From: David Kastrup @ 2005-10-25 22:07 UTC (permalink / raw) Cc: ding Jesper Harder <jesper.harder@gmail.com> writes: > Uwe Brauer <oub@mat.ucm.es> writes: > >>>>>>> "David" == David Kastrup <dak@gnu.org> writes: >> >> David> M-x elp-results RET >> >> Thanks, this function also exists in xemacs (and I did not know >> about it), in any case the information is very aehm spare: > > You should probably also instrument the `nnml', `imap', `mm' and `mml' > packages (and maybe some more depending on which operation you're > benchmarking -- I don't recall). And it helps to run the test first before instrumenting it: that way not only the autoloads get instrumented. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-25 22:07 ` David Kastrup @ 2005-10-26 9:32 ` Uwe Brauer 2005-10-27 1:02 ` Ben Wing 0 siblings, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2005-10-26 9:32 UTC (permalink / raw) Cc: xemacs-beta >>>>> "David" == David Kastrup <dak@gnu.org> writes: >> >>>>>>>> "David" == David Kastrup <dak@gnu.org> writes: >>> David> M-x elp-results RET >>> >>> Thanks, this function also exists in xemacs (and I did not know >>> about it), in any case the information is very aehm spare: >> >> You should probably also instrument the `nnml', `imap', `mm' and `mml' >> packages (and maybe some more depending on which operation you're >> benchmarking -- I don't recall). David> And it helps to run the test first before instrumenting it: that way David> not only the autoloads get instrumented. Ok, thanks, I think now more or less I know how to proceed. As I said before the situation is sort of strange: for a certain amount of msg, say n, both emacsen are almost equal, gnu emacs a little faster, once the number of msg > n, then xemacs got stacked. I should add, that the information of the elp packages is detailed the profile-command of xemacs gives far more information. I don't know how important profiling is for emacs, but may that pkg could be ported? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-26 9:32 ` Uwe Brauer @ 2005-10-27 1:02 ` Ben Wing 2005-10-27 9:24 ` Uwe Brauer ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Ben Wing @ 2005-10-27 1:02 UTC (permalink / raw) Cc: ding, xemacs-beta Uwe Brauer wrote: >>>>>>"David" == David Kastrup <dak@gnu.org> writes: >>>>>> >>>>>> > >> > >>>>>>>> "David" == David Kastrup <dak@gnu.org> writes: > >>> > David> M-x elp-results RET > >>> > >>> Thanks, this function also exists in xemacs (and I did not know > >>> about it), in any case the information is very aehm spare: > >> > >> You should probably also instrument the `nnml', `imap', `mm' and `mml' > >> packages (and maybe some more depending on which operation you're > >> benchmarking -- I don't recall). > > > David> And it helps to run the test first before instrumenting it: that way > David> not only the autoloads get instrumented. > >Ok, thanks, I think now more or less I know how to proceed. As I said >before the situation is sort of strange: for a certain amount of msg, >say n, both emacsen are almost equal, gnu emacs a little faster, once >the number of msg > n, then xemacs got stacked. > > it would be very nice to know where the problem is. sometimes typing Control-Shift-G in XEmacs will break out and give you a backtrace. (it should always do that but maybe sometimes doesn't ...) If not, try setting Options->Troubleshooting->Debug on Quit, then manually do `kill -INT ###', where ### is the process id of XEmacs. (maybe it's `kill -SIGINT ###', i forget) >I should add, that the information of the elp packages is detailed the >profile-command of xemacs gives far more information. I don't know how >important profiling is for emacs, but may that pkg could be ported? > > the problem is that the XEmacs profile stuff depends on C support, which is how it's able to do all the nifty things it does. ben ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-27 1:02 ` Ben Wing @ 2005-10-27 9:24 ` Uwe Brauer 2005-10-28 9:52 ` Uwe Brauer 2005-10-28 10:04 ` Uwe Brauer 2 siblings, 0 replies; 22+ messages in thread From: Uwe Brauer @ 2005-10-27 9:24 UTC (permalink / raw) Cc: ding >>>>> "Ben" == Ben Wing <ben@xemacs.org> writes: Ben> Uwe Brauer wrote: >> >> Ben> it would be very nice to know where the problem is. sometimes Ben> typing it seems that it has to do with the size of the msg. Mails with large attachment are the problem in xemacs, but still I have to look that up in detail. Ben> Control-Shift-G in XEmacs will break out and give you a Ben> backtrace. (it should always do that but maybe sometimes Ben> doesn't ...) If not, try setting Ben> Options->Troubleshooting->Debug on Quit, then manually do Ben> `kill -INT ###', where ### is the process id of XEmacs. (maybe Ben> it's `kill -SIGINT ###', i forget) problem is that under recent X-free versions the shift key does not work properly, that is control shift g, is the same as control g for xemacs, but I do as you suggest set is debug on quit. I report back, Uwe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-27 1:02 ` Ben Wing 2005-10-27 9:24 ` Uwe Brauer @ 2005-10-28 9:52 ` Uwe Brauer 2005-10-28 11:09 ` Simon Josefsson 2005-10-28 10:04 ` Uwe Brauer 2 siblings, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2005-10-28 9:52 UTC (permalink / raw) Cc: xemacs-beta >>>>> "Ben" == Ben Wing <ben@xemacs.org> writes: Ben> Uwe Brauer wrote: >> >> Ben> it would be very nice to know where the problem is. Ben> sometimes typing Control-Shift-G in XEmacs will break out Ben> and give you a backtrace. (it should always do that but Ben> maybe sometimes doesn't ...) If not, try setting Ben> Options->Troubleshooting->Debug on Quit, then manually do Ben> `kill -INT ###', where ### is the process id of Ben> XEmacs. (maybe it's `kill -SIGINT ###', i forget) Ok, I continued with the testing: - the problem does not occur when copying a large amount of msg between nnml servers! Xemacs is as fast as gnu emacs - the problem seem to be connected with `large' msg: msg with an attachment >0.5 Mega. I tried this with xemacs -vanilla either nognus-0.3 or the actual xemacs pkg release. Now xemacs does not really get stack, after some Control g key strokes I can continue typing (and even with debug-on-signal t no useful backtrace is produced). However the nnimap command got *stacked*. I can not leave neither the group not the server The command lisp-process lists me the imap command imap open *nnimap* ucimap.ucm.es (none) network stream connection 143@ucimap.ucm.es could please somebody confirm this? But I don't know how to kill that process, ps ux does not list that process. Again that problem does not occur in gnu emacs and now I begin to understand why me complains about the slowness of the nnimap command were ignored on the gnus list: it seems to be more of a xemacs problem. If someone could suggest me how to enhance the testing in order to localise the problem... Regards Uwe Brauer ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 9:52 ` Uwe Brauer @ 2005-10-28 11:09 ` Simon Josefsson 2005-10-28 11:55 ` Uwe Brauer 2005-10-28 12:06 ` Uwe Brauer 0 siblings, 2 replies; 22+ messages in thread From: Simon Josefsson @ 2005-10-28 11:09 UTC (permalink / raw) Cc: xemacs-beta, ding Uwe Brauer <oub@mat.ucm.es> writes: > The command > lisp-process > lists me the imap command > > imap open *nnimap* ucimap.ucm.es (none) network stream > connection 143@ucimap.ucm.es > > But I don't know how to kill that process, ps ux does not list that > process. Kill the buffer " *nnimap *ucimap.ucm.es" (note leading SPC). > If someone could suggest me how to enhance the testing in order to > localise the problem... Instrument imap* and nnimap* for ELP. Note that nnimap is likely to be slowed than nnml, but I'm not sure what magnitude of "slower" you are talking about here. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 11:09 ` Simon Josefsson @ 2005-10-28 11:55 ` Uwe Brauer 2005-10-28 12:27 ` Simon Josefsson 2005-10-28 12:06 ` Uwe Brauer 1 sibling, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2005-10-28 11:55 UTC (permalink / raw) Cc: xemacs-beta >>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: Simon> Uwe Brauer <oub@mat.ucm.es> writes: Simon> Kill the buffer " *nnimap *ucimap.ucm.es" (note leading SPC). >> If someone could suggest me how to enhance the testing in order to >> localise the problem... Simon> Instrument imap* and nnimap* for ELP. Note that nnimap is I did elp-instrument-package gnus (which I thought include everyting) Or or profile-command (gnus-summary-copy-article) for xemacs. But right I do as you say Simon> likely to be slowed than nnml, but I'm not sure what Simon> magnitude of "slower" you are talking about here. Get stacked, I mean not doing anything (xemacs) compared to perform a operation (gnu emacs) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 11:55 ` Uwe Brauer @ 2005-10-28 12:27 ` Simon Josefsson 0 siblings, 0 replies; 22+ messages in thread From: Simon Josefsson @ 2005-10-28 12:27 UTC (permalink / raw) Cc: xemacs-beta, ding Uwe Brauer <oub@mat.ucm.es> writes: >>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: > > Simon> Uwe Brauer <oub@mat.ucm.es> writes: > > Simon> Kill the buffer " *nnimap *ucimap.ucm.es" (note leading SPC). > > >> If someone could suggest me how to enhance the testing in order to > >> localise the problem... > > Simon> Instrument imap* and nnimap* for ELP. Note that nnimap is > I did elp-instrument-package gnus (which I thought include everyting) No, the (nn)imap functions in Gnus doesn't use the gnus function name prefix, you need to instrument them manually. Same for message, mm, pgg, sieve etc. > Simon> likely to be slowed than nnml, but I'm not sure what > Simon> magnitude of "slower" you are talking about here. > > Get stacked, I mean not doing anything (xemacs) compared to perform a > operation (gnu emacs) Aha. Ok. That's bad. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 11:09 ` Simon Josefsson 2005-10-28 11:55 ` Uwe Brauer @ 2005-10-28 12:06 ` Uwe Brauer 2005-10-28 12:28 ` Simon Josefsson 1 sibling, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2005-10-28 12:06 UTC (permalink / raw) Cc: xemacs-beta >>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: >> >> But I don't know how to kill that process, ps ux does not list that >> process. Simon> Kill the buffer " *nnimap *ucimap.ucm.es" (note leading SPC). That buffer does not exist in my case. I can only see the process but I don't have that buffer (in xemacs-21.4.17) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 12:06 ` Uwe Brauer @ 2005-10-28 12:28 ` Simon Josefsson 2005-10-28 14:05 ` Uwe Brauer 0 siblings, 1 reply; 22+ messages in thread From: Simon Josefsson @ 2005-10-28 12:28 UTC (permalink / raw) Cc: xemacs-beta, ding Uwe Brauer <oub@mat.ucm.es> writes: >>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: > >> > >> But I don't know how to kill that process, ps ux does not list that > >> process. > > Simon> Kill the buffer " *nnimap *ucimap.ucm.es" (note leading SPC). > > That buffer does not exist in my case. I can only see the process but > I don't have that buffer (in xemacs-21.4.17) Sorry, I meant " *nnimap* ucimap.ucm.es". Try typing `C-x b SPC *nnimap*' and use TAB completion. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 12:28 ` Simon Josefsson @ 2005-10-28 14:05 ` Uwe Brauer 2005-10-28 14:31 ` Simon Josefsson 0 siblings, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2005-10-28 14:05 UTC (permalink / raw) Cc: xemacs-beta >>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: [snip] Simon> Sorry, I meant " *nnimap* ucimap.ucm.es". Try typing `C-x b Simon> SPC *nnimap*' and use TAB completion. Ok that works, however since the process get stacked I don't get any reasonable backtrace. If somebody could confirm, that for large msg nnimap copying does not work properly under xemacs? Uwe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 14:05 ` Uwe Brauer @ 2005-10-28 14:31 ` Simon Josefsson 2005-10-28 15:53 ` Uwe Brauer 0 siblings, 1 reply; 22+ messages in thread From: Simon Josefsson @ 2005-10-28 14:31 UTC (permalink / raw) Cc: xemacs-beta, ding Uwe Brauer <oub@mat.ucm.es> writes: >>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: > > > [snip] > > > Simon> Sorry, I meant " *nnimap* ucimap.ucm.es". Try typing `C-x b > Simon> SPC *nnimap*' and use TAB completion. > > Ok that works, however since the process get stacked I don't get any > reasonable backtrace. I don't understand. Does XEmacs freeze completely? If so, I don't think there is anything we can do at the Elisp level. It must be debugged as an XEmacs bug. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 14:31 ` Simon Josefsson @ 2005-10-28 15:53 ` Uwe Brauer 2005-10-31 7:05 ` Ben Wing 0 siblings, 1 reply; 22+ messages in thread From: Uwe Brauer @ 2005-10-28 15:53 UTC (permalink / raw) Cc: xemacs-beta >>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: >> >> Ok that works, however since the process get stacked I don't get any >> reasonable backtrace. Simon> I don't understand. Does XEmacs freeze completely? If so, I don't Simon> think there is anything we can do at the Elisp level. It must be Simon> debugged as an XEmacs bug. No what I say is: I want to copy that msg and xemacs starts to tell me copying msg, but nothing happens after 2 min after several Control g I can type again, however it seems that the nnimap command is stacked, I cannot leave the group nor the server, but I have to do what you told me. So for me it not clear who is to blame. However that problem does not occur in gnu emacs with the same gnus (ngnus 0.3) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-28 15:53 ` Uwe Brauer @ 2005-10-31 7:05 ` Ben Wing 0 siblings, 0 replies; 22+ messages in thread From: Ben Wing @ 2005-10-31 7:05 UTC (permalink / raw) Cc: xemacs-beta, ding Uwe Brauer wrote: >>>>>>"Simon" == Simon Josefsson <jas@extundo.com> writes: >>>>>> >>>>>> > > >> > >> Ok that works, however since the process get stacked I don't get any > >> reasonable backtrace. > > Simon> I don't understand. Does XEmacs freeze completely? If so, I don't > Simon> think there is anything we can do at the Elisp level. It must be > Simon> debugged as an XEmacs bug. > >No what I say is: I want to copy that msg and xemacs starts to tell me >copying msg, but nothing happens after 2 min after several Control g I >can type again, however it seems that the nnimap command is stacked, I >cannot leave the group nor the server, but I have to do what you told >me. > >So for me it not clear who is to blame. However that problem does not >occur in gnu emacs with the same gnus (ngnus 0.3) > > a backtrace would help. i assume you're running under linux? you can do `ps -auxww' or `ps -edalf' or something like that to list all processes, and then attach to the xemacs process that's hung, and do `where' to get a c backtrace and `call debug_backtrace()' to get a lisp backtrace. one of the faq questions in section 2.4 covers this in more detail. ben ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-27 1:02 ` Ben Wing 2005-10-27 9:24 ` Uwe Brauer 2005-10-28 9:52 ` Uwe Brauer @ 2005-10-28 10:04 ` Uwe Brauer 2 siblings, 0 replies; 22+ messages in thread From: Uwe Brauer @ 2005-10-28 10:04 UTC (permalink / raw) Cc: xemacs-beta >>>>> "Ben" == Ben Wing <ben@xemacs.org> writes: >> >> Ben> it would be very nice to know where the problem is. sometimes Ben> typing Control-Shift-G in XEmacs will break out and give you a Ben> backtrace. (it should always do that but maybe sometimes Ben> doesn't ...) If not, try setting Ben> Options->Troubleshooting->Debug on Quit, then manually do Ben> `kill -INT ###', where ### is the process id of XEmacs. (maybe Ben> it's `kill -SIGINT ###', i forget) I forgot to add: in my nnimap folder/groups I have activated Gcc (to that group) so that, via the nnimap command, my reply to a mail is copied to that nnimap group. That command as well gets *stacked*, but not in gnu emacs! So I have the feeling that nnimap is not optimized for xemacs to put it mildly. Uwe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Speed difference in Gnus 2005-10-24 16:52 ` Uwe Brauer 2005-10-24 18:24 ` David Kastrup @ 2005-10-24 21:00 ` Reiner Steib 1 sibling, 0 replies; 22+ messages in thread From: Reiner Steib @ 2005-10-24 21:00 UTC (permalink / raw) On Mon, Oct 24 2005, Uwe Brauer wrote: > Could somebody of the gnu folks[1] please point me out how to profile a > command in either gnu emacs 21 or 22. ,---- | elp-instrument-function M-x ... RET | Command: Instrument FUNSYM for profiling. | elp-instrument-list M-x ... RET | Command: Instrument for profiling, all functions in `elp-function-list'. | elp-instrument-package M-x ... RET | Command: Instrument for profiling, all functions which start with PREFIX. | elp-results M-x ... RET | Command: Display current profiling results. `---- Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2005-10-31 7:05 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <87r7ap899o.fsf@xemacs.org> 2005-10-13 21:17 ` Speed difference in Gnus Reiner Steib [not found] ` <434EFD44.7030601@xemacs.org> [not found] ` <877jcgub0f.fsf@xemacs.org> [not found] ` <434F3897.3050007@xemacs.org> [not found] ` <873bn4tptq.fsf@xemacs.org> [not found] ` <87d5m89wuf.fsf@tleepslib.sk.tsukuba.ac.jp> [not found] ` <87y84nyuo0.fsf@mat.ucm.es> [not found] ` <873bmulscb.fsf@tleepslib.sk.tsukuba.ac.jp> [not found] ` <87pspypwzv.fsf@mat.ucm.es> [not found] ` <sluuli82.fsf@smtprelay.t-online.de> 2005-10-24 16:52 ` Uwe Brauer 2005-10-24 18:24 ` David Kastrup 2005-10-25 9:50 ` Uwe Brauer 2005-10-25 10:48 ` David Kastrup 2005-10-25 17:50 ` Jesper Harder 2005-10-25 22:07 ` David Kastrup 2005-10-26 9:32 ` Uwe Brauer 2005-10-27 1:02 ` Ben Wing 2005-10-27 9:24 ` Uwe Brauer 2005-10-28 9:52 ` Uwe Brauer 2005-10-28 11:09 ` Simon Josefsson 2005-10-28 11:55 ` Uwe Brauer 2005-10-28 12:27 ` Simon Josefsson 2005-10-28 12:06 ` Uwe Brauer 2005-10-28 12:28 ` Simon Josefsson 2005-10-28 14:05 ` Uwe Brauer 2005-10-28 14:31 ` Simon Josefsson 2005-10-28 15:53 ` Uwe Brauer 2005-10-31 7:05 ` Ben Wing 2005-10-28 10:04 ` Uwe Brauer 2005-10-24 21:00 ` Reiner Steib
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).