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

Re: too snappy?

Expand Messages
  • Ben Schmidt
    ... OK. My MacVim clone/convert/etc. was taking ages so I left it unattended and then forgot about it, but I ve got it moving again now, so soon I ll be able
    Message 1 of 23 , Aug 2, 2008
    • 0 Attachment
      björn wrote:
      > 2008/8/2 Ben Schmidt <mail_ben_schmidt@...>:
      >> 1. Do we have any real evidence of what the bottleneck is? Are we
      >> assuming it's the loading of the rc files when it's some other aspect of
      >> startup which can be optimised without the side effects that occur if we
      >> pre-read rc files, or at least where we could get the same benefit by
      >> optimising something else? My experience is that often the first
      >> instance takes close to a second, but after that (presumably because
      >> files are cached) it only takes about 0.35 seconds. (This is without
      >> quickstart.) But in the terminal, where almost as many rc files are read
      >> (no menus, but otherwise pretty much the same), it takes something like
      >> 0.15 seconds (after they're cached). So, apart from a cold start, on
      >> this evidence, the non-menu rc file reading at worst can account for
      >> 0.15 seconds of loading time, and thus a very insignificant speed up. If
      >> larger differences are seen in MacVim, perhaps it's an indication that
      >> :menu commands should be optimised.
      > I don't think menu loading slows things down that much since disabling
      > all menu loading did not noticeably cut down on the startup times. I
      > could be wrong since I did not test this very carefully (and I did a
      > while back).

      OK. My MacVim clone/convert/etc. was taking ages so I left it unattended
      and then forgot about it, but I've got it moving again now, so soon I'll
      be able to see the snappiness of that patch with my own eyes. Still, I
      wonder why (1) the preloading makes such a large difference and (2) it's
      so much slower in MacVim vs. console Vim anyway. It sure would be nice
      to really know for sure what the bottleneck is.

      >> 2. Could a compromise be something like this: when you choose New
      >> Window, MacVim immediately opens a new GUI window, but with no content
      >> (just a grey background or something); that window is just a placeholder
      >> waiting for a Vim process. Then alter MacVim so that when a Vim process
      >> connects to it, it uses an existing 'waiting' window if one exists, and
      >> if not, opens a new one (so mvim would still work, etc.). There would be
      >> no need to associate waiting windows with specific Vim processes--any
      >> Vim process could get assigned to any waiting window and it wouldn't
      >> matter. The point is that the user would get immediate visual feedback
      >> that they'd successfully pressed Command-N/chosen the menu item, even
      >> though the Vim process would take a little while to load before the
      >> window gets content. It acts like a "Loading. Please wait." message but
      >> without the tackiness. Much like starting an app in OS X--you get the
      >> immediate feedback of the bouncing dock icon, and once you see that,
      >> you're happy to wait for the app to appear: you know it's on its way.
      >> What's more, if MacVim has a bunch of GUI initialisation that needs to
      >> be done and can be done independently of Vim, it could happen in
      >> parallel with Vim startup this way which might help, too, particularly
      >> when Vim is blocking for file reads.
      > This is something I have been thinking about too and it doesn't seem
      > like such a bad idea. The only thing that stopped me from going down
      > this road was that I'm not sure what the initial window size should
      > be. It will probably look silly if the window has to resize as soon
      > as the Vim process finishes loading. Also, if the :winpos command is
      > implemented, the window may also "jump" when the process finishes
      > loading. These two issues makes me wonder if this solution is ever
      > going to work very well.

      I personally don't think window jumping/resizing is a problem,
      particularly since it would only occur with user intervention (i.e. if
      you installed a plugin to make use of winpos/columns/lines or use them
      in your vimrc or such). I'm sure I see other apps do this to their
      windows, too, and it doesn't bother me; I can't think of an example off
      the top of my head, though, and it may well not be a native Mac app.
      Where does MacVim get the size from currently? The lines and columns
      options, along with the guifont? I think it's fair enough to use either
      the lines, columns and font from the previously opened window, or
      (Mac)Vim defaults for this and let it change when Vim connects if

      Another option would be showing a small progress window (e.g. one of
      those stripy progress bars) that then expands to full size when Vim
      connects. I'd suggest still making that small progress window the actual
      MacVim window, though, so that any Cocoa initialisation, etc. can be
      done on that window, rather than needing to close that one and open a
      new one when Vim connects. Though perhaps initialising a hidden window
      and showing a generic progress window is another option.


      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.