#164 working over ssh extremely slow

General (289)

Ubuntu 8.04 x64
Geany 0.14 and svn 0.15

Gnome mounted SSH volumes to server.

When working with SSH files that have been opened with nautilus via "open with geany", the application slows and becomes more and more unresponsive over time.

The time to save files is considerably longer than the same file being saved using Gedit, which is always swift.

As the problem gets worse it becomes laborious to type as the typed characters start to catch up with what was written.

I only get the problem when editing ssh mounted files. The delays in saving and the subsequent unresponsive nature of the interface means I can't continue to use Geany, which is a shame because it's a fantastic editor.


  • Nick Treleaven

    Nick Treleaven - 2008-06-12

    Logged In: YES
    Originator: NO

    Which SVN revision have you tried (check 'svn info')? Does it occur with the latest (run 'svn up' and rebuild)? Does it occur if you set the 'Disk check timeout' Files pref to 0?

    Geany doesn't read files over SSH directly, did you use the ~/.gvfs folder or FUSE to access them?

  • Nobody/Anonymous

    Logged In: NO

    I have the same issue. Editing files opened via gvfs is really slow, you have 1-2 secs to wait each time you press a key.
    Saving time is also a bit long but that is not a big issue for me.

    I use gvfs (up to date Ubuntu 8), and Geany 0.14.

    Where can I change 'Disk check timeout' Files pref to 0 ?

    codspirit -at- gmail -dot- com

  • Nick Treleaven

    Nick Treleaven - 2008-06-24

    Logged In: YES
    Originator: NO

    > Where can I change 'Disk check timeout' Files pref to 0 ?

    In the Edit->Preferences dialog, click the Files tab, then under the Miscellaneous heading, it's the second preference.

  • adam chapman

    adam chapman - 2008-07-03

    Logged In: YES
    Originator: NO

    I have updated now to r2742 and will make some more tests. I use the gvfs to mount SSH and work from there. As said, it's no problem at all in GEdit working in exactly the same way.

    I have changed this disk setting and will report back again.

  • adam chapman

    adam chapman - 2008-07-03

    Logged In: YES
    Originator: NO

    The problems still exist. None of the suggestions help. It takes an age to load and save files over gvfs in comparison to gedit.

  • Enrico Tröger

    Enrico Tröger - 2008-07-13

    Logged In: YES
    Originator: NO

    In the meantime, I also played with GVFS/Fuse and I can confirm working with Geany over more or less slow server connections can be feel slow and laggy.
    But once I disabled the "disk check timeout" by setting it to 0, all worked fine without any noticeably delay. I was using latest SVN.

  • adam chapman

    adam chapman - 2008-10-08

    This is still a big problem with todays SVN version and Ubuntu Hardy.

    It takes 7 seconds to save the same PHP file over SSH that gedit can do in less than 2 seconds.

    It's very disappointing that such a thing still hasn't been addressed within so many months.

    The disc access check makes no difference.

    It's easy to replicate....

    put ssh://servname:port in nautilus
    Open a remote file with geany
    Make a change
    Press save

    It will sit for 5 seconds, then the screen will darken for 2 seconds and your changes will be saved.

  • Enrico Tröger

    Enrico Tröger - 2008-10-08

    I'm attaching a patch which adds a timer to the save function.
    This shows pretty good where the problem in the delay while saving is: tagmanager.

    While saving a C file with about 250KB, I got these values over an average FTP connection using GVFS/Fuse:
    ** INFO: 0.014246: write data to file
    ** INFO: 2.675760: data written to file
    ** INFO: 4.626260: get_real_path_from_utf8() finished
    ** INFO: 4.627577: document_update_timestamp() finished
    ** INFO: /home/enrico/.gvfs/.../tmp/interface.c : C (UTF-8)
    ** INFO: 6.809261: document_set_filetype() finished
    ** INFO: 6.970291: tm_workspace_update() finished

    So, it took 6.9 seconds to save the file. But writing the contents to the file (using a FTP connection this means the upload), took only 2.6 seconds.
    The remaining time is lost with post-save actions, mostly updating the symbol list. This is because the tagmanager, the code to parse the contents for the symbol list works on files and so it has to open the file again after saving, on a remote FS this means downloading. This happens in document_set_filetype().

    The other interesting place is get_real_path_from_utf8() which took also about 2 seconds. Basically in this function we call only the C function realpath(). Maybe we can avoid at least partly this delay when we call realpath() only if the file is actually a symlink, for regular files this function isn't necessary, AFAIK. This probably would speed up the whole thing a bit as I guess most files on remote systems aren't symlinks.

    In the long term, we probably need to make the tagmanager working with buffers instead of files. I remember Anjuta did this(?), after Geany 0.15, I will look into this and check what can be done.

  • Enrico Tröger

    Enrico Tröger - 2008-10-08

    Timing information when saving files

  • Enrico Tröger

    Enrico Tröger - 2008-12-21

    Update: since SVN r3412 things are a little better: Geany now uses realpath() only if necessary instead of at every save operation and it doesn't update the file's timestamp when checking for changes on disk is disabled (saves one stat() on the file).

    These changes don't solve the problems but make them a little smaller, at least.

    The earlier mentioned changes to the tagmanager to work on buffers instead of files are still to come but this means a lot of work.

  • Nobody/Anonymous

    I will have a look at the latest geany build. Seems a big improvement (comparable to gedit) if you can save under 3 seconds now.

    Thanks for keeping on top of this!

  • Anonymous - 2012-09-13
    • status: open --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks