Loading ...
Sorry, an error occurred while loading the content.

Re: Making vim fast

Expand Messages
  • A.J.Mechelynck
    ... I ve heard X11 can make a big difference at Vim startup (not once Vim is loaded) when it s not possible to connect with an X server: when an X-enabled Vim
    Message 1 of 1 , Sep 25, 2006
    • 0 Attachment
      panshizhu@... 寫:
      > "A.J.Mechelynck" <antoine.mechelynck@...> 写于 2006-09-26 08:35:38:
      >> I don't know about reverting to 6.4 but it's always a tradeoff between
      >> features and speed.
      >>
      >> Best regards,
      >> Tony.
      >
      > My experience is that the feature does not affect running speed too much.
      > Only for startup speed.
      >
      > I'd compared my Vim7 and Vim64, only the startup is slower for Vim7, and
      > when Vim is up and running, no noticable speed difference...
      >
      > If he just feel slow when opening file inside Vim, then IMO it makes little
      > difference reducing any Vim features like X11...
      >
      > If some of the plugin could be disabled, then it does make difference IMO.
      > Since plugin scripts runs much slower than Vim executable itself.
      >
      > --
      > Sincerely, Pan, Shi Zhu. ext: 2606
      >
      >

      I've heard X11 can make a big difference at Vim startup (not once Vim is
      loaded) when it's not possible to connect with an X server: when an X-enabled
      Vim (with or without GUI) is loaded, it tries to make contact with the X
      clipboard. If there is no X server running, or if loaded in a terminal like
      /dev/tty which cannot reach the X server, Vim waits for a timeout before
      deciding that it won't be using X11 this time. To avoid that timeout, then
      when no X server is available, either load Vim as "vim -X", or use a
      non-X-aware console version.

      Personally, I am using a Vim 7 version with as many features as I could lay
      hands on (huge Gnome2 GUI, +perl +python +ruby +tcl), and I notice no undue
      slowness, except of course on really huge files (e.g. a version of the Unicode
      "Unihan.txt" to which I'm currently adding some data "for my personal use
      only": that particular file has more than one million lines) where
      searching-and-not-finding, searching in the wrong direction (with wrap from
      bottom to top or vice-versa), and also writing, can take tens of seconds. But
      I suppose that on a slower machine, on one with less "live" memory, or with a
      less patient user ;-), eliminating unneeded features might make more of a
      difference than on my machine, or maybe on yours.


      Best regards,
      Tony.
    Your message has been successfully submitted and would be delivered to recipients shortly.