* 22.1.50; insert-file-contents is slow under tramp @ 2007-08-23 12:33 Stephen Berman 2007-08-23 14:25 ` martin rudalics 0 siblings, 1 reply; 30+ messages in thread From: Stephen Berman @ 2007-08-23 12:33 UTC (permalink / raw) To: emacs-pretest-bug 1. emacs -Q 2. I type C-x d and at the prompt type "/localhost:/ RET" and when prompted type my user password and then complete the path to some directory that contains a fairly large file (> 1MB is enough to clearly show the problem), e.g. the lisp directory of the Emacs sources. 3. I put the cursor on a large file, e.g. ChangeLog.12 (1251246 bytes) and press RET. On my machine it takes ~20 seconds for the buffer visiting this file to appear and during that time emacs is consuming almost 100% CPU. If at step 2 I directly enter the path to the lisp directory of the Emacs sources, avoiding tramp, and then do step 3, the buffer appears almost instantly, as usual. So the slowdown is only with tramp (also if I use a different user, e.g. with /su::/, which is how I first encountered the problem). The slowdown seems to be proportional to the size of the file, so not too long (but noticeable) with small files. Using edebug I found the slowdown occurs when insert-file-contents is called in find-file-noselect-1. I don't know how to debug it further. This slowdown did not exist in my previous Emacs build from 2007-06-30. In GNU Emacs 22.1.50.7 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-08-21 on escher Windowing system distributor `The X.Org Foundation', version 11.0.70199902 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-agent-mode: t shell-dirtrack-mode: t gnus-topic-mode: t gnus-undo-mode: t tabbar-mwheel-mode: t tabbar-mode: t recentf-mode: t display-time-mode: t show-paren-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t temp-buffer-resize-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: identity Recent input: <return> e s <tab> <backspace> r <tab> s <tab> c v <tab> e <tab> / l i <tab> <M-backspace> l i s <tab> <return> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <return> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <tool-bar> <kill-buffer> <tool-bar> <kill-buffer> C-c j m a <tab> <return> <up> <up> <up> <up> <up> <up> / o 5 0 0 <return> <home> C-s t r a m C-w C-s C-s C-a <down> <down> <down> C-s C-s C-r C-r <left> SPC <up> SPC <f1> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <down> <up> SPC <f1> <down-mouse-1> <mouse-2> <select-window> <select-window> <help-echo> <f1> <down> q M-x r e p o <tab> r <tab> b <tab> <return> Recent messages: Fetching headers for gmane.emacs.devel...done Loading cl-seq...done Loading cl-extra...done Generating summary...done Mark set Mark saved where search started [2 times] Loading w3m-symbol...done Loading w3m-form...done Making completion list... Loading emacsbug...done ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 12:33 22.1.50; insert-file-contents is slow under tramp Stephen Berman @ 2007-08-23 14:25 ` martin rudalics 2007-08-23 15:02 ` Stephen Berman 0 siblings, 1 reply; 30+ messages in thread From: martin rudalics @ 2007-08-23 14:25 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-pretest-bug [-- Attachment #1: Type: text/plain, Size: 380 bytes --] > Using edebug I found the slowdown occurs when insert-file-contents is > called in find-file-noselect-1. I don't know how to debug it further. > This slowdown did not exist in my previous Emacs build from 2007-06-30. Stefan found a bug in my recent changes to `insert-file-contents'. I can't tell whether it's related to your problem but could you try with the attached patch? [-- Attachment #2: fileio.patch --] [-- Type: text/plain, Size: 2673 bytes --] *** fileio.c Sat Aug 18 09:50:08 2007 --- fileio.c Thu Aug 23 11:04:32 2007 *************** *** 4733,4746 **** int opoint = PT; int opoint_byte = PT_BYTE; int oinserted = ZV - BEGV; TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE); insval = call3 (Qformat_decode, Qnil, make_number (oinserted), visit); CHECK_NUMBER (insval); ! if (XINT (insval) == oinserted) SET_PT_BOTH (opoint, opoint_byte); ! inserted = XFASTINT (insval); } /* For consistency with format-decode call these now iff inserted > 0 --- 4733,4753 ---- int opoint = PT; int opoint_byte = PT_BYTE; int oinserted = ZV - BEGV; + int ochars_modiff = CHARS_MODIFF; TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE); insval = call3 (Qformat_decode, Qnil, make_number (oinserted), visit); CHECK_NUMBER (insval); ! if (ochars_modiff == CHARS_MODIFF) ! /* format_decode didn't modify buffer's characters => move ! point back to position before inserted text and leave ! value of inserted alone. */ SET_PT_BOTH (opoint, opoint_byte); ! else ! /* format_decode modified buffer's characters => consider ! entire buffer changed and leave point at point-min. */ ! inserted = XFASTINT (insval); } /* For consistency with format-decode call these now iff inserted > 0 *************** *** 4763,4777 **** int opoint = PT; int opoint_byte = PT_BYTE; int oinserted = ZV - BEGV; ! TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE); insval = call1 (XCAR (p), make_number (oinserted)); if (!NILP (insval)) { CHECK_NUMBER (insval); ! if (XINT (insval) == oinserted) SET_PT_BOTH (opoint, opoint_byte); ! inserted = XFASTINT (insval); } } --- 4770,4793 ---- int opoint = PT; int opoint_byte = PT_BYTE; int oinserted = ZV - BEGV; ! int ochars_modiff = CHARS_MODIFF; ! TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE); insval = call1 (XCAR (p), make_number (oinserted)); if (!NILP (insval)) { CHECK_NUMBER (insval); ! if (ochars_modiff == CHARS_MODIFF) ! /* after_insert_file_functions didn't modify ! buffer's characters => move point back to ! position before inserted text and leave value of ! inserted alone. */ SET_PT_BOTH (opoint, opoint_byte); ! else ! /* after_insert_file_functions did modify buffer's ! characters => consider entire buffer changed and ! leave point at point-min. */ ! inserted = XFASTINT (insval); } } [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 14:25 ` martin rudalics @ 2007-08-23 15:02 ` Stephen Berman 2007-08-23 17:49 ` martin rudalics 0 siblings, 1 reply; 30+ messages in thread From: Stephen Berman @ 2007-08-23 15:02 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-pretest-bug On Thu, 23 Aug 2007 16:25:32 +0200 martin rudalics <rudalics@gmx.at> wrote: >> Using edebug I found the slowdown occurs when insert-file-contents is >> called in find-file-noselect-1. I don't know how to debug it further. >> This slowdown did not exist in my previous Emacs build from 2007-06-30. > > Stefan found a bug in my recent changes to `insert-file-contents'. > I can't tell whether it's related to your problem but could you try > with the attached patch? It doesn't make a very big difference: it takes 17 seconds to open ChangeLog.12 as opposed to 20 seconds without the patch. (I assume I did it right: applied the patch and ran make in emacs/src to rebuild the emacs executable, without recompiling the lisp files.) Steve Berman ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 15:02 ` Stephen Berman @ 2007-08-23 17:49 ` martin rudalics 2007-08-23 18:59 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: martin rudalics @ 2007-08-23 17:49 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-pretest-bug > It doesn't make a very big difference: it takes 17 seconds to open > ChangeLog.12 as opposed to 20 seconds without the patch. (I assume I > did it right: applied the patch and ran make in emacs/src to rebuild > the emacs executable, without recompiling the lisp files.) I suppose you don't want to run insert-file-contents with gdb. Could you try to edebug format-decode and tell whether the 17 secs are spent before calling it, while running it, or after calling it. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 17:49 ` martin rudalics @ 2007-08-23 18:59 ` Stefan Monnier 2007-08-23 20:25 ` martin rudalics 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2007-08-23 18:59 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-pretest-bug, Stephen Berman >> It doesn't make a very big difference: it takes 17 seconds to open >> ChangeLog.12 as opposed to 20 seconds without the patch. (I assume I >> did it right: applied the patch and ran make in emacs/src to rebuild >> the emacs executable, without recompiling the lisp files.) > I suppose you don't want to run insert-file-contents with gdb. > Could you try to edebug format-decode and tell whether the 17 secs are > spent before calling it, while running it, or after calling it. I think this has nothing to do with it: Tramp implements insert-file-contents in Elisp. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 18:59 ` Stefan Monnier @ 2007-08-23 20:25 ` martin rudalics 2007-08-23 20:39 ` Stephen Berman 0 siblings, 1 reply; 30+ messages in thread From: martin rudalics @ 2007-08-23 20:25 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-pretest-bug, Stephen Berman > I think this has nothing to do with it: Tramp implements insert-file-contents > in Elisp. I was puzzled because according to the OP >> ... the slowdown occurs when insert-file-contents is >> called in find-file-noselect-1. Stephen could you tell us how this relates to tramp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 20:25 ` martin rudalics @ 2007-08-23 20:39 ` Stephen Berman 2007-08-23 21:01 ` martin rudalics [not found] ` <46CDF5B7.2030201@g\x04mx.at> 0 siblings, 2 replies; 30+ messages in thread From: Stephen Berman @ 2007-08-23 20:39 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-pretest-bug On Thu, 23 Aug 2007 19:49:39 +0200 martin rudalics <rudalics@gmx.at> wrote: >> It doesn't make a very big difference: it takes 17 seconds to open >> ChangeLog.12 as opposed to 20 seconds without the patch. (I assume I >> did it right: applied the patch and ran make in emacs/src to rebuild >> the emacs executable, without recompiling the lisp files.) > > I suppose you don't want to run insert-file-contents with gdb. See below. > Could you try to edebug format-decode and tell whether the 17 secs are > spent before calling it, while running it, or after calling it. The 17 seconds elapse before format-decode is called. On Thu, 23 Aug 2007 22:25:15 +0200 martin rudalics <rudalics@gmx.at> wrote: >> I think this has nothing to do with it: Tramp implements insert-file-contents >> in Elisp. > > I was puzzled because according to the OP > >>> ... the slowdown occurs when insert-file-contents is >>> called in find-file-noselect-1. > > Stephen could you tell us how this relates to tramp. Stefan is right, and I was wrong, but didn't see it until running under gdb, as you suggested. I set a breakpoint at fileio.c:3689 (the beginning of the insert-file-contents DEFUN). After going through the tramp stuff and typing RET on ChangeLog.12, execution stopped at the breakpoint: Breakpoint 3, Finsert_file_contents (filename=142792571, visit=137492729, beg=137492681, end=137492681, replace=137492681) at fileio.c:3714 3714 { (gdb) n 3720 int count = SPECPDL_INDEX (); (gdb) n 3733 Lisp_Object old_Vdeactivate_mark = Vdeactivate_mark; (gdb) n 3714 { (gdb) n 3720 int count = SPECPDL_INDEX (); (gdb) n 3736 if (current_buffer->base_buffer && ! NILP (visit)) (gdb) n 3720 int count = SPECPDL_INDEX (); (gdb) n 3733 Lisp_Object old_Vdeactivate_mark = Vdeactivate_mark; (gdb) n 3736 if (current_buffer->base_buffer && ! NILP (visit)) (gdb) n 3739 if (!NILP (current_buffer->read_only)) (gdb) n 3742 val = Qnil; (gdb) n 3749 CHECK_STRING (filename); (gdb) n 3742 val = Qnil; (gdb) n 3749 CHECK_STRING (filename); (gdb) n 3750 filename = Fexpand_file_name (filename, Qnil); (gdb) n 3754 handler = Ffind_file_name_handler (filename, Qinsert_file_contents); (gdb) n 3755 if (!NILP (handler)) (gdb) n 3754 handler = Ffind_file_name_handler (filename, Qinsert_file_contents); (gdb) n 3755 if (!NILP (handler)) (gdb) n 3757 val = call6 (handler, Qinsert_file_contents, filename, (gdb) n Warning: Cannot insert breakpoint -129. Error accessing memory address 0x9317cb93: Input/output error. Then I typed `c' and got the 17 second interval where emacs consumed almost all the CPU, then the breakpoint stopped execution again and I got the following backtrace: #0 Finsert_file_contents (filename=143060787, visit=137492681, beg=137492681, end=137492681, replace=137492681) at fileio.c:3714 #1 0x0815eadf in Ffuncall (nargs=6, args=0xbfd47f60) at eval.c:3040 #2 0x0818992d in Fbyte_code (bytestr=139911115, vector=142565700, maxdepth=<value optimized out>) at bytecode.c:679 #3 0x0815e4fa in funcall_lambda (fun=142194052, nargs=5, arg_vector=0xbfd480a4) at eval.c:3213 #4 0x0815e901 in Ffuncall (nargs=6, args=0xbfd480a0) at eval.c:3083 #5 0x08160226 in Fapply (nargs=2, args=0xbfd48164) at eval.c:2514 #6 0x0815ec25 in Ffuncall (nargs=3, args=0xbfd48160) at eval.c:3007 #7 0x0818992d in Fbyte_code (bytestr=139908699, vector=142139364, maxdepth=<value optimized out>) at bytecode.c:679 #8 0x0815e4fa in funcall_lambda (fun=142170892, nargs=6, arg_vector=0xbfd48284) at eval.c:3213 #9 0x0815e901 in Ffuncall (nargs=7, args=0xbfd48280) at eval.c:3083 #10 0x08160226 in Fapply (nargs=3, args=0xbfd48344) at eval.c:2514 #11 0x0815ec25 in Ffuncall (nargs=4, args=0xbfd48340) at eval.c:3007 #12 0x0818992d in Fbyte_code (bytestr=139908827, vector=142220436, maxdepth=<value optimized out>) at bytecode.c:679 #13 0x0815e4fa in funcall_lambda (fun=142655764, nargs=6, arg_vector=0xbfd48464) at eval.c:3213 #14 0x0815e901 in Ffuncall (nargs=7, args=0xbfd48460) at eval.c:3083 #15 0x0815ec49 in call6 (fn=138355337, arg1=137611529, arg2=142719987, arg3=137492729, arg4=137492681, arg5=137492681, arg6=137492681) at eval.c:2931 #16 0x08129b28 in Finsert_file_contents (filename=142719987, visit=137492729, beg=137492681, end=137492681, replace=137492681) at fileio.c:3757 #17 0x0815eadf in Ffuncall (nargs=3, args=0xbfd5cbd0) at eval.c:3040 #18 0x0818992d in Fbyte_code (bytestr=136198155, vector=136198180, maxdepth=<value optimized out>) at bytecode.c:679 #19 0x0815dfb5 in Feval (form=136198141) at eval.c:2363 #20 0x0816063f in internal_lisp_condition_case (var=137492681, bodyform=136198141, handlers=136198213) at eval.c:1433 #21 0x08188c25 in Fbyte_code (bytestr=136197731, vector=136197748, maxdepth=<value optimized out>) at bytecode.c:869 #22 0x0815e4fa in funcall_lambda (fun=136197660, nargs=6, arg_vector=0xbfd5cef4) at eval.c:3213 #23 0x0815e901 in Ffuncall (nargs=7, args=0xbfd5cef0) at eval.c:3083 #24 0x0818992d in Fbyte_code (bytestr=136196795, vector=136196812, maxdepth=<value optimized out>) at bytecode.c:679 #25 0x0815e4fa in funcall_lambda (fun=136196724, nargs=4, arg_vector=0xbfd5d024) at eval.c:3213 #26 0x0815e901 in Ffuncall (nargs=5, args=0xbfd5d020) at eval.c:3083 #27 0x0818992d in Fbyte_code (bytestr=136192091, vector=136192108, maxdepth=<value optimized out>) at bytecode.c:679 #28 0x0815e4fa in funcall_lambda (fun=136192036, nargs=1, arg_vector=0xbfd5d154) ---Type <return> to continue, or q <return> to quit--- at eval.c:3213 #29 0x0815e901 in Ffuncall (nargs=2, args=0xbfd5d150) at eval.c:3083 #30 0x0818992d in Fbyte_code (bytestr=139566787, vector=142412436, maxdepth=<value optimized out>) at bytecode.c:679 #31 0x0815e4fa in funcall_lambda (fun=142412572, nargs=0, arg_vector=0xbfd5d274) at eval.c:3213 #32 0x0815e901 in Ffuncall (nargs=1, args=0xbfd5d270) at eval.c:3083 #33 0x08160379 in apply1 (fn=142392345, arg=137492681) at eval.c:2767 #34 0x0815ba00 in Fcall_interactively (function=142392345, record_flag=137492681, keys=137533996) at callint.c:406 #35 0x080fac73 in Fcommand_execute (cmd=142392345, record_flag=137492681, keys=137492681, special=137492681) at keyboard.c:10119 #36 0x0810684b in command_loop_1 () at keyboard.c:1873 #37 0x0815d492 in internal_condition_case (bfun=0x81064d0 <command_loop_1>, handlers=137538137, hfun=0x8100e20 <cmd_error>) at eval.c:1488 #38 0x08100263 in command_loop_2 () at keyboard.c:1329 #39 0x0815d54a in internal_catch (tag=137531321, func=0x8100240 <command_loop_2>, arg=137492681) at eval.c:1229 #40 0x08100c5c in command_loop () at keyboard.c:1308 #41 0x08100ffb in recursive_edit_1 () at keyboard.c:1006 #42 0x081010e6 in Frecursive_edit () at keyboard.c:1067 #43 0x080f6dd0 in main (argc=2, argv=0xbfd5db14) at emacs.c:1774 Lisp Backtrace: "insert-file-contents" (0x886ef33) "tramp-handle-insert-file-contents" (0x881bbf3) "apply" (0x88013b9) "tramp-sh-file-name-handler" (0x833c909) "apply" (0x88014c1) "tramp-file-name-handler" (0x833c909) "insert-file-contents" (0x883cdfb) "byte-code" (0x81e380b) "find-file-noselect-1" (0x884a17c) "find-file-noselect" (0x883ffab) "find-file" (0x883ffab) "dired-advertised-find-file" (0x831f8c9) "call-interactively" (0x87cbc19) So the slowdown is at insert-file-contents, but the invocation is from tramp, which I did not see when using edebug before. I tried edebugging in tramp but could not get any further than tramp-file-name-handler. Hopefully someone else (Michael Albinus?) can. Steve Berman ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 20:39 ` Stephen Berman @ 2007-08-23 21:01 ` martin rudalics [not found] ` <46CDF5B7.2030201@g\x04mx.at> 1 sibling, 0 replies; 30+ messages in thread From: martin rudalics @ 2007-08-23 21:01 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-pretest-bug > 3754 handler = Ffind_file_name_handler (filename, Qinsert_file_contents); > (gdb) n > 3755 if (!NILP (handler)) > (gdb) n > 3757 val = call6 (handler, Qinsert_file_contents, filename, Did you edebug `tramp-handle-insert-file-contents'? ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <46CDF5B7.2030201@g\x04mx.at>]
* Re: 22.1.50; insert-file-contents is slow under tramp [not found] ` <46CDF5B7.2030201@g\x04mx.at> @ 2007-08-23 21:40 ` Stephen Berman 2007-08-24 5:34 ` Michael Albinus ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Stephen Berman @ 2007-08-23 21:40 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-pretest-bug On Thu, 23 Aug 2007 23:01:43 +0200 martin rudalics <rudalics@gmx.at> wrote: >> 3754 handler = Ffind_file_name_handler (filename, Qinsert_file_contents); >> (gdb) n >> 3755 if (!NILP (handler)) >> (gdb) n >> 3757 val = call6 (handler, Qinsert_file_contents, filename, > > Did you edebug `tramp-handle-insert-file-contents'? Yes, and the slowdown occurs on evalling (file-local-copy filename). In file-local-copy the slowdown occurs at (funcall handler 'file-local-copy file), and the value of `handler' is tramp-file-name-handler and that's where I got stuck. Edebug iterates over it hundreds, maybe thousands of times. If I just hold down `f' on this function eventually the slowdown occurs, but I cannot see where within it. If I tried stepping through it, I'd probably be at it all night. So I hope there's a better way. Steve Berman ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 21:40 ` Stephen Berman @ 2007-08-24 5:34 ` Michael Albinus 2007-08-24 7:18 ` Stephen Berman 2007-08-24 14:32 ` Stefan Monnier 2007-08-24 9:28 ` Eli Zaretskii 2007-08-24 16:10 ` Richard Stallman 2 siblings, 2 replies; 30+ messages in thread From: Michael Albinus @ 2007-08-24 5:34 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-pretest-bug, emacs-devel Stephen Berman <Stephen.Berman@gmx.net> writes: > So I hope there's a better way. Yes. I've installed a patch in the trunk, which makes a fast track for "remote" files being on localhost. For real remote hosts, I recommend to use scp when accessing huge files. > Steve Berman Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-24 5:34 ` Michael Albinus @ 2007-08-24 7:18 ` Stephen Berman 2007-08-24 14:32 ` Stefan Monnier 1 sibling, 0 replies; 30+ messages in thread From: Stephen Berman @ 2007-08-24 7:18 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-pretest-bug On Fri, 24 Aug 2007 07:34:18 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: > Stephen Berman <Stephen.Berman@gmx.net> writes: > >> So I hope there's a better way. > > Yes. I've installed a patch in the trunk, which makes a fast track for > "remote" files being on localhost. I confirm that fixes the problem; many thanks! > For real remote hosts, I recommend to use scp when accessing huge files. Thanks for the tip. Steve Berman ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-24 5:34 ` Michael Albinus 2007-08-24 7:18 ` Stephen Berman @ 2007-08-24 14:32 ` Stefan Monnier 2007-08-26 10:36 ` Michael Albinus 2007-08-27 10:52 ` Michael Albinus 1 sibling, 2 replies; 30+ messages in thread From: Stefan Monnier @ 2007-08-24 14:32 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel >> So I hope there's a better way. > Yes. I've installed a patch in the trunk, which makes a fast track for > "remote" files being on localhost. How does that work? I mean when accessing files on the localhost with Tramp, the most likely situation I can think of is the `su' method so how what does your "fast track" do to transfer the file faster? Does it copy it to /tmp at the "remote" end, then make it world-readable, then copy it on the "local" end, then remove it at the remote end? > For real remote hosts, I recommend to use scp when accessing huge files. Reminds me: where is the bottleneck in the inline method? I mean fundamentally doing a base64 encoding/decoding shouldn't cost that much (negligible CPU-wise and a mere 33% in network transfer). Maybe we could attack this part to improve performance? Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-24 14:32 ` Stefan Monnier @ 2007-08-26 10:36 ` Michael Albinus 2007-08-26 19:01 ` David Kastrup 2007-08-27 4:16 ` Stefan Monnier 2007-08-27 10:52 ` Michael Albinus 1 sibling, 2 replies; 30+ messages in thread From: Michael Albinus @ 2007-08-26 10:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Yes. I've installed a patch in the trunk, which makes a fast track for >> "remote" files being on localhost. > > How does that work? I mean when accessing files on the localhost with > Tramp, the most likely situation I can think of is the `su' method so how > what does your "fast track" do to transfer the file faster? Does it copy it > to /tmp at the "remote" end, then make it world-readable, then copy it on > the "local" end, then remove it at the remote end? Similar approach. It calls `tramp-do-copy-or-rename-file-directly', which copies the "remote" file to /tmp, and assigns proper permissions. Then `insert-file-contents' for the _local_ temporary file is applied, which shows the file in the buffer, and the temporary file is deleted. >> For real remote hosts, I recommend to use scp when accessing huge files. > > Reminds me: where is the bottleneck in the inline method? I mean > fundamentally doing a base64 encoding/decoding shouldn't cost that much > (negligible CPU-wise and a mere 33% in network transfer). Maybe we could > attack this part to improve performance? I haven't investigated too much. mimencode and base64-decode are pretty fast, even on my stone-age machine, with an 8MB sized file: | (with-current-buffer (get-buffer-create "foo") | (elp-instrument-function 'call-process) | (elp-instrument-function 'base64-decode-region) | (erase-buffer) | | (call-process "mimencode" nil t nil "/var/cache/apt/pkgcache.bin") | (base64-decode-region (point-min) (point-max)) | (elp-results)) | | Function Name Call Count Elapsed Time Average Time | ==================== ========== ============ ============ | base64-decode-region 1 7.732203 7.732203 | call-process 1 1.917887 1.917887 But with the installed "fast track", it is remarkable faster than even these two basic functions: | (with-current-buffer (get-buffer-create "foo") | (elp-instrument-function 'insert-file-contents) | (erase-buffer) | (setq tramp-verbose 0) | | ;; This opens the connection, including password handover etc | (file-attributes "/sudo::") | | (insert-file-contents "/sudo::/var/cache/apt/pkgcache.bin") | (elp-results)) | | Function Name Call Count Elapsed Time Average Time | ==================== ========== ============ ============ | insert-file-contents 2 1.64688 0.82344 Without the fast track, the access time is inacceptable large. I suspect that `tramp-wait-for-output' is the bottleneck, because it must check for the resulting shell prompt, handle echoing shells, etc. I will investigate next days whether there can be an improvement. > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-26 10:36 ` Michael Albinus @ 2007-08-26 19:01 ` David Kastrup 2007-08-26 19:24 ` Michael Albinus 2007-08-27 4:16 ` Stefan Monnier 1 sibling, 1 reply; 30+ messages in thread From: David Kastrup @ 2007-08-26 19:01 UTC (permalink / raw) To: Michael Albinus Cc: emacs-pretest-bug, Stephen Berman, Stefan Monnier, emacs-devel Michael Albinus <michael.albinus@gmx.de> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >>> Yes. I've installed a patch in the trunk, which makes a fast track for >>> "remote" files being on localhost. >> >> How does that work? I mean when accessing files on the localhost with >> Tramp, the most likely situation I can think of is the `su' method so how >> what does your "fast track" do to transfer the file faster? Does it copy it >> to /tmp at the "remote" end, then make it world-readable, then copy it on >> the "local" end, then remove it at the remote end? > > Similar approach. It calls `tramp-do-copy-or-rename-file-directly', > which copies the "remote" file to /tmp, and assigns proper > permissions. Then `insert-file-contents' for the _local_ temporary > file is applied, which shows the file in the buffer, and the > temporary file is deleted. For the su and sudo functions, in many (but not all) cases the file is actually world-readable (things like /etc/fstab or /etc/passwd). Making use of that would probably be by far the fastest way for getting the file. Do you do this already? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-26 19:01 ` David Kastrup @ 2007-08-26 19:24 ` Michael Albinus 0 siblings, 0 replies; 30+ messages in thread From: Michael Albinus @ 2007-08-26 19:24 UTC (permalink / raw) To: David Kastrup Cc: emacs-pretest-bug, Stephen Berman, Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: > For the su and sudo functions, in many (but not all) cases the file is > actually world-readable (things like /etc/fstab or /etc/passwd). > Making use of that would probably be by far the fastest way for > getting the file. > > Do you do this already? Not yet. I'll check. Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-26 10:36 ` Michael Albinus 2007-08-26 19:01 ` David Kastrup @ 2007-08-27 4:16 ` Stefan Monnier 2007-08-27 11:41 ` Michael Albinus 1 sibling, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2007-08-27 4:16 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel >>> Yes. I've installed a patch in the trunk, which makes a fast track for >>> "remote" files being on localhost. >> >> How does that work? I mean when accessing files on the localhost with >> Tramp, the most likely situation I can think of is the `su' method so how >> what does your "fast track" do to transfer the file faster? Does it copy it >> to /tmp at the "remote" end, then make it world-readable, then copy it on >> the "local" end, then remove it at the remote end? > Similar approach. It calls `tramp-do-copy-or-rename-file-directly', > which copies the "remote" file to /tmp, and assigns proper > permissions. What would be proper permissions? I mean: how do you make sure that some nasty third party won't be able to read the content of that temp file, while still making it possible for Emacs to access the file? > I haven't investigated too much. mimencode and base64-decode are pretty > fast, even on my stone-age machine, with an 8MB sized file: > | (with-current-buffer (get-buffer-create "foo") > | (elp-instrument-function 'call-process) > | (elp-instrument-function 'base64-decode-region) > | (erase-buffer) > | > | (call-process "mimencode" nil t nil "/var/cache/apt/pkgcache.bin") > | (base64-decode-region (point-min) (point-max)) > | (elp-results)) > | > | Function Name Call Count Elapsed Time Average Time > | ==================== ========== ============ ============ > | base64-decode-region 1 7.732203 7.732203 > | call-process 1 1.917887 1.917887 > But with the installed "fast track", it is remarkable faster than even > these two basic functions: 1MB/s for base64 sounds terribly slow. My 266MHz home-router can send and encrypt data from disk to the network at about that speed. But admittedly, we're not talking `mimencode' but base64-decode-region which may include a lot of overhead to extract and insert data from/to the buffer. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 4:16 ` Stefan Monnier @ 2007-08-27 11:41 ` Michael Albinus 2007-08-27 13:58 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Michael Albinus @ 2007-08-27 11:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Similar approach. It calls `tramp-do-copy-or-rename-file-directly', >> which copies the "remote" file to /tmp, and assigns proper >> permissions. > > What would be proper permissions? I mean: how do you make sure that some > nasty third party won't be able to read the content of that temp file, while > still making it possible for Emacs to access the file? The current approach(1) is to remove any temporary file immediately after it has been processes by Emacs (for example, insert-file-contents is finished). This reduces the time nasty third party can see such a file. But I admit, this might not be sufficient wrt security threats. Maybe one could change it such a way, that temporary files shall be owned by (user-login-name), and shall carry 0400 permissions. (1): That's the theory. In practice, there are still some zero-length temporary files left, for which I haven't debugged yet who is responsible to remove them. On my todo list. > 1MB/s for base64 sounds terribly slow. My 266MHz home-router can send > and encrypt data from disk to the network at about that speed. > But admittedly, we're not talking `mimencode' but base64-decode-region which > may include a lot of overhead to extract and insert data from/to the buffer. Don't take the absolute values, I just wanted to show the comparison. Tests were run on my stone-age 700MHz PIII machine. > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 11:41 ` Michael Albinus @ 2007-08-27 13:58 ` Stefan Monnier 2007-08-27 14:09 ` Thien-Thi Nguyen ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Stefan Monnier @ 2007-08-27 13:58 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel > The current approach(1) is to remove any temporary file immediately after > it has been processes by Emacs (for example, insert-file-contents is > finished). This reduces the time nasty third party can see such a file. If the file is readable, that's a major security concern. > But I admit, this might not be sufficient wrt security threats. Maybe > one could change it such a way, that temporary files shall be owned by > (user-login-name), and shall carry 0400 permissions. How can you do that? Let's say I access a file of user BAR from user FOO, how would you go about doing it in such a way that user TOTO can never see the content of the file? BAR can't use `chown' (unless it's root). > (1): That's the theory. In practice, there are still some zero-length > temporary files left, for which I haven't debugged yet who is > responsible to remove them. On my todo list. Oh, I've sen those. Yes, they need fixing as well, but it's minor: this is not a security concern. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 13:58 ` Stefan Monnier @ 2007-08-27 14:09 ` Thien-Thi Nguyen 2007-08-27 14:14 ` David Kastrup 2007-08-27 14:53 ` Michael Albinus 2 siblings, 0 replies; 30+ messages in thread From: Thien-Thi Nguyen @ 2007-08-27 14:09 UTC (permalink / raw) To: emacs-devel () Stefan Monnier <monnier@iro.umontreal.ca> () Mon, 27 Aug 2007 09:58:32 -0400 How can you do that? Let's say I access a file of user BAR from user FOO, how would you go about doing it in such a way that user TOTO can never see the content of the file? BAR can't use `chown' (unless it's root). can we use tmpfile(3)? thi ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 13:58 ` Stefan Monnier 2007-08-27 14:09 ` Thien-Thi Nguyen @ 2007-08-27 14:14 ` David Kastrup 2007-08-27 14:53 ` Michael Albinus 2 siblings, 0 replies; 30+ messages in thread From: David Kastrup @ 2007-08-27 14:14 UTC (permalink / raw) To: Stefan Monnier Cc: emacs-pretest-bug, Stephen Berman, Michael Albinus, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> The current approach(1) is to remove any temporary file immediately after >> it has been processes by Emacs (for example, insert-file-contents is >> finished). This reduces the time nasty third party can see such a file. > > If the file is readable, that's a major security concern. > >> But I admit, this might not be sufficient wrt security threats. Maybe >> one could change it such a way, that temporary files shall be owned by >> (user-login-name), and shall carry 0400 permissions. > > How can you do that? Let's say I access a file of user BAR from > user FOO, how would you go about doing it in such a way that user > TOTO can never see the content of the file? BAR can't use `chown' > (unless it's root). Huh? We are talking about tramp here. The file is transferred through a ssh session. On the receiving side, you'll be free to create a file with whatever permissions you want, and on the sending side, no change of permissions is required to access the file. -- David Kastrup ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 13:58 ` Stefan Monnier 2007-08-27 14:09 ` Thien-Thi Nguyen 2007-08-27 14:14 ` David Kastrup @ 2007-08-27 14:53 ` Michael Albinus 2007-08-27 20:11 ` Stefan Monnier 2 siblings, 1 reply; 30+ messages in thread From: Michael Albinus @ 2007-08-27 14:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > How can you do that? Let's say I access a file of user BAR from user FOO, > how would you go about doing it in such a way that user TOTO can never see > the content of the file? BAR can't use `chown' (unless it's root). BAR must give away the ownership of the temporary file to FOO. See this test (BAR is albinus, FOO is hostmann). Any TOTO cannot see the contents of the file, despite she is root - in this case we can forget security at all. # whoami albinus # touch stefan # chmod 0400 stefan # ll stefan -r-------- 1 albinus smc3 0 Aug 27 16:36 stefan # chown hostmann stefan # ll stefan -r-------- 1 hostmann smc3 0 Aug 27 16:36 stefan # cat stefan cat: stefan: Permission denied Note that we are speaking about temporary files. Either FOO or BAR is always me (locally), for the other user I have a Tramp connection capable to send UNIX commands. I can send commands under both user permissions in the order I do need. It's a kind of puzzling who must give ownership to whom (it depends on the copying direction), but it's a finite number of cases only. > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 14:53 ` Michael Albinus @ 2007-08-27 20:11 ` Stefan Monnier 2007-08-27 20:37 ` Michael Albinus 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2007-08-27 20:11 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel > # whoami > albinus > # touch stefan > # chmod 0400 stefan > # ll stefan > -r-------- 1 albinus smc3 0 Aug 27 16:36 stefan > # chown hostmann stefan > # ll stefan > -r-------- 1 hostmann smc3 0 Aug 27 16:36 stefan > # cat stefan > cat: stefan: Permission denied Can you tell me which systems allow you to do that? I know that under *BSD there were ways to do that, allowed or not depending on some global setting because such user-transfer of file ownership can be a security hole in itself. Basically only `root' can use `chown' on modern POSIX systems, AFAIK. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 20:11 ` Stefan Monnier @ 2007-08-27 20:37 ` Michael Albinus 0 siblings, 0 replies; 30+ messages in thread From: Michael Albinus @ 2007-08-27 20:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > Can you tell me which systems allow you to do that? I know that under *BSD > there were ways to do that, allowed or not depending on some global setting > because such user-transfer of file ownership can be a security hole in > itself. Basically only `root' can use `chown' on modern POSIX > systems, AFAIK. You're right, I've tested under HP-UX 11.11. Here @home, with Ubuntu, it is not permitted (although the chown man page doesn't mention this restriction). Hmm, my proposal would work only when the source file belongs to root, accessed by Tramp. This is the most important case, though. Other temporary files, coming from the local host or a remote host, might be readable for third parties. One could try that all temporary files are only readable for the local user (who needs to access these files for insert-file-contents etc), but this must be checked. Copying without the "-p" option, or so. I will sleep about. Another idea would be a special temp directory as user option, where the user is forced to apply 700 permissions for this directory. > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-24 14:32 ` Stefan Monnier 2007-08-26 10:36 ` Michael Albinus @ 2007-08-27 10:52 ` Michael Albinus 2007-08-27 11:33 ` David Kastrup 1 sibling, 1 reply; 30+ messages in thread From: Michael Albinus @ 2007-08-27 10:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-pretest-bug, Stephen Berman, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Reminds me: where is the bottleneck in the inline method? I mean > fundamentally doing a base64 encoding/decoding shouldn't cost that much > (negligible CPU-wise and a mere 33% in network transfer). Maybe we could > attack this part to improve performance? The major bottleneck is `accept-process-output', which returns only small chunks when called again and again. With a `sleep-for' between two calls, I have improved the performance (but not dramatically). However, this approach would require to manage when it is desired to apply `sleep-for', and when not. Most of the commands, Tramp sends to the remote host, return just one or two lines of output. I guess it isn't worth the trouble. For local hosts, I have implemented the fast track (satisfying su and sudo); in all other cases accessing huge files, scp (or pscp) shall be sufficient. > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 10:52 ` Michael Albinus @ 2007-08-27 11:33 ` David Kastrup 2007-08-27 18:18 ` Richard Stallman 0 siblings, 1 reply; 30+ messages in thread From: David Kastrup @ 2007-08-27 11:33 UTC (permalink / raw) To: Michael Albinus Cc: emacs-pretest-bug, Stephen Berman, Stefan Monnier, emacs-devel Michael Albinus <michael.albinus@gmx.de> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> Reminds me: where is the bottleneck in the inline method? I mean >> fundamentally doing a base64 encoding/decoding shouldn't cost that >> much (negligible CPU-wise and a mere 33% in network transfer). >> Maybe we could attack this part to improve performance? > > The major bottleneck is `accept-process-output', which returns only > small chunks when called again and again. With a `sleep-for' between > two calls, I have improved the performance (but not dramatically). Same old scheduler problem that prompted both of w32-pipe-read-delay process-adaptive-read-buffering Maybe you should try setting process-adaptive-read-buffering to a non-nil non-t value? -- David Kastrup ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 11:33 ` David Kastrup @ 2007-08-27 18:18 ` Richard Stallman 2007-08-27 18:51 ` David Kastrup 0 siblings, 1 reply; 30+ messages in thread From: Richard Stallman @ 2007-08-27 18:18 UTC (permalink / raw) To: David Kastrup Cc: emacs-pretest-bug, Stephen.Berman, michael.albinus, monnier, emacs-devel > The major bottleneck is `accept-process-output', which returns only > small chunks when called again and again. With a `sleep-for' between > two calls, I have improved the performance (but not dramatically). Same old scheduler problem that prompted both of w32-pipe-read-delay process-adaptive-read-buffering Maybe you should try setting process-adaptive-read-buffering to a non-nil non-t value? Should the defaults for any of these be changed? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-27 18:18 ` Richard Stallman @ 2007-08-27 18:51 ` David Kastrup 0 siblings, 0 replies; 30+ messages in thread From: David Kastrup @ 2007-08-27 18:51 UTC (permalink / raw) To: rms Cc: emacs-pretest-bug, Stephen.Berman, michael.albinus, monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > > The major bottleneck is `accept-process-output', which returns only > > small chunks when called again and again. With a `sleep-for' between > > two calls, I have improved the performance (but not dramatically). > > Same old scheduler problem that prompted both of > > w32-pipe-read-delay > process-adaptive-read-buffering > > Maybe you should try setting process-adaptive-read-buffering to a > non-nil non-t value? > > Should the defaults for any of these be changed? It is hard to say: basically, they work around deficiencies in the CPU schedulers of the respective operating systems. Linux is supposed to get CFS, "completely fair scheduling" in its next released version, something like 2.6.23. This should quite help with the original problem. Not because of fairness, but because of being different: pretty much _any_ scheduler should behave better here than the previous "context switch whenever possible" scheduling strategy. I was actually surprised to see w32-pipe-read-delay crop up in my apropos-documentation search. From the description, it sounds like it addresses a similar problem, so perhaps it might have been made redundant by process-adaptive-read-buffering _if_ the latter does its job reasonably well under Windows. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 21:40 ` Stephen Berman 2007-08-24 5:34 ` Michael Albinus @ 2007-08-24 9:28 ` Eli Zaretskii 2007-08-24 9:35 ` Stephen Berman 2007-08-24 16:10 ` Richard Stallman 2 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2007-08-24 9:28 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-pretest-bug > From: Stephen Berman <Stephen.Berman@gmx.net> > Date: Thu, 23 Aug 2007 23:40:22 +0200 > Cc: emacs-devel@gnu.org > > > Did you edebug `tramp-handle-insert-file-contents'? > > Yes, and the slowdown occurs on evalling (file-local-copy filename). > In file-local-copy the slowdown occurs at (funcall handler > 'file-local-copy file), and the value of `handler' is > tramp-file-name-handler and that's where I got stuck. Edebug iterates > over it hundreds, maybe thousands of times. If I just hold down `f' > on this function eventually the slowdown occurs, but I cannot see > where within it. If I tried stepping through it, I'd probably be at > it all night. So I hope there's a better way. For the future: there _is_ a better way: use the elp.el package to profile the command, and you should be able to see which function consumes the most of the time. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-24 9:28 ` Eli Zaretskii @ 2007-08-24 9:35 ` Stephen Berman 0 siblings, 0 replies; 30+ messages in thread From: Stephen Berman @ 2007-08-24 9:35 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-pretest-bug On Fri, 24 Aug 2007 12:28:24 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <Stephen.Berman@gmx.net> >> Date: Thu, 23 Aug 2007 23:40:22 +0200 >> Cc: emacs-devel@gnu.org >> >> > Did you edebug `tramp-handle-insert-file-contents'? >> >> Yes, and the slowdown occurs on evalling (file-local-copy filename). >> In file-local-copy the slowdown occurs at (funcall handler >> 'file-local-copy file), and the value of `handler' is >> tramp-file-name-handler and that's where I got stuck. Edebug iterates >> over it hundreds, maybe thousands of times. If I just hold down `f' >> on this function eventually the slowdown occurs, but I cannot see >> where within it. If I tried stepping through it, I'd probably be at >> it all night. So I hope there's a better way. > > For the future: there _is_ a better way: use the elp.el package to > profile the command, and you should be able to see which function > consumes the most of the time. Thanks for the tip! Steve Berman ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 22.1.50; insert-file-contents is slow under tramp 2007-08-23 21:40 ` Stephen Berman 2007-08-24 5:34 ` Michael Albinus 2007-08-24 9:28 ` Eli Zaretskii @ 2007-08-24 16:10 ` Richard Stallman 2 siblings, 0 replies; 30+ messages in thread From: Richard Stallman @ 2007-08-24 16:10 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-pretest-bug, emacs-devel If I just hold down `f' on this function eventually the slowdown occurs, but I cannot see where within it. If I tried stepping through it, I'd probably be at it all night. How about typing C-z during the slow part? Then make a backtrace and you'll see what it's doing. If you try that a few times you should see a pattern. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2007-08-27 20:37 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-23 12:33 22.1.50; insert-file-contents is slow under tramp Stephen Berman
2007-08-23 14:25 ` martin rudalics
2007-08-23 15:02 ` Stephen Berman
2007-08-23 17:49 ` martin rudalics
2007-08-23 18:59 ` Stefan Monnier
2007-08-23 20:25 ` martin rudalics
2007-08-23 20:39 ` Stephen Berman
2007-08-23 21:01 ` martin rudalics
[not found] ` <46CDF5B7.2030201@g\x04mx.at>
2007-08-23 21:40 ` Stephen Berman
2007-08-24 5:34 ` Michael Albinus
2007-08-24 7:18 ` Stephen Berman
2007-08-24 14:32 ` Stefan Monnier
2007-08-26 10:36 ` Michael Albinus
2007-08-26 19:01 ` David Kastrup
2007-08-26 19:24 ` Michael Albinus
2007-08-27 4:16 ` Stefan Monnier
2007-08-27 11:41 ` Michael Albinus
2007-08-27 13:58 ` Stefan Monnier
2007-08-27 14:09 ` Thien-Thi Nguyen
2007-08-27 14:14 ` David Kastrup
2007-08-27 14:53 ` Michael Albinus
2007-08-27 20:11 ` Stefan Monnier
2007-08-27 20:37 ` Michael Albinus
2007-08-27 10:52 ` Michael Albinus
2007-08-27 11:33 ` David Kastrup
2007-08-27 18:18 ` Richard Stallman
2007-08-27 18:51 ` David Kastrup
2007-08-24 9:28 ` Eli Zaretskii
2007-08-24 9:35 ` Stephen Berman
2007-08-24 16:10 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).