time of upload takes seconds (ssh, tramp issue?)
jeswcollins opened this issue · 15 comments
A colleague said their editor (Sublime) takes only about 100 ms to upload a file to a server. They thought Sublime was using sftp so one question is how does this time depend on the protocol used, but in my experience, ssh typically takes one or more seconds with emacs and ssh-deploy. So I thought I should ask about the time uploads take with ssh-deploy. Should the time be comparable to other editor/protocol configurations? Does anyone have 100 ms upload times with emacs/ssh/ssh-deploy?
It depends on connection and computer setup. You can speed up tramp SSH if you configure your machine to use controlmaster. I usually have upload times below a second, I think I get 100ms on some connections
Thanks for the info. Mine just took about 10 seconds. Maybe I should test my ssh separately.
scp with the same file is under 2 seconds.
2 seconds for scp compared to 100ms in Sublime, I doubt Sublime is faster than scp.. But Emacs should be close to scp at least for small files. If you have enabled revisions then ssh-deploy will diff remote file for external changes, that process probably doubles the execution time. Try using a forced upload that bypasses that and check upload time
Thanks for the info. I tried a forced upload (via menu Deployment->Forced Upload). The time was comparable or longer to upload at saving (13 seconds compared to 10). I haven't to my knowledge enabled revisions.
Since the uploads are asynchronous, I must not have really noticed how long they were taking, but maybe relevant in the case of issues I reported previously?
I think ControlMaster was enabled (could share the lines I have in my config file but similar to what I see elsewhere on the internet). So I'm not sure really sure what to make of the time discrepancy I have between scp and tramp, but maybe we can reasonably close this issue and I could look into tramp more.
After a little more digging, I think my Tramp might be taking a long time to parse the remote prompt.
I think that you should time the upload time of the emacs-lisp (copy-file LOCAL-FILE REMOTE-FILE t t t t) because it's basically what ssh-deploy does so the issue is probably in Tramp. In my experience Tramp can be very fast with some servers (ssh or ftp) and slow with others but it's most often faster or comparable with i.e. PhpStorm. Maybe Sublime Text is more optimized for transfers but it would be weird if it's faster than scp, since scp should be very optimized
I tried M-x copy-file <RET> and copied the same file over. I timed the process at 2.85 seconds.
I was surprised because I was thinking my 10+ seconds were probably due to Tramp taking time to parse the colorful remote prompt I have. Was reading these links about remote prompts and Tramp: https://stackoverflow.com/a/8363532/895065 and https://www.gnu.org/software/emacs/manual/html_node/tramp/Frequently-Asked-Questions.html
One recommendation for a slow Tramp is "use an external method like scp"(https://www.gnu.org/software/emacs/manual/html_node/tramp/Frequently-Asked-Questions.html). I tried scp in my tramp default and .dir-locals but upload time was similar (10+ s).
Ok is ssh-deploy slower than tramp-only? Are you using async transfers?
Yes, it seems that tramp-only is faster than ssh-deploy (<3 vs. >10 seconds).
Yes, with ssh-deploy I am using async transfers.
Ok try time upload with synchronous transfer, maybe async.el adds significant overhead
You found the overhead! Synchronous upload took what I timed to be 1.87 seconds. Same file asynchronously took ~12 seconds. Not sure what's better for me. Will probably stick with asynchronous but wish it didn't take so long.
Emacs does not at the moment have good asynchronous support, async.el and with-editor.el starts a new emacs process via a asynchronous process so there is a lot of unnecessary overhead. The built-in support for asynchronous threads are even slower than async.el at the moment. I'm closing this since it's not an issue with ssh-deploy.el