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

Re: too snappy?

Expand Messages
  • dv1445@wayne.edu
    ... Ah, I just noticed that when MacVim occasionally fails to open a new window (one of the minor problems mentioned above), it still *thinks* they re open.
    Message 1 of 23 , Aug 1 1:37 PM
    • 0 Attachment
      Thus spake björn [08/01/08 @ 21.52.18 +0200]:
      > The public repo now contains the "quickstart" feature but it is
      > disabled by default because I have noticed intermittent (but rare)
      > problems with opening/closing windows (nothing fatal, just annoying
      > log messages and problems with windows never opening). Despite this I
      > myself have it enabled all the time and it is working fine under
      > normal circumstances. To enable, open up Terminal and enter
      >
      > defaults write org.vim.MacVim MMPreloadCacheSize 2

      Ah, I just noticed that when MacVim occasionally fails to open a new window (one of the minor problems mentioned above), it still *thinks* they're open. To see this, just try Cmd-Q after a failed open when no windows are visible. MacVim gives a dialog that says something like "are you sure you want to quit even with 2 windows still open?".

      I can live with these issues until they gradually fall away as MacVim evolves.
      -gmn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • 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 2 of 23 , Aug 2 3:26 AM
      • 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
        necessary.

        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.

        Ben.



        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • dv1445@wayne.edu
        ... Hmmm... well, I certainly don t just forget about the delay, and I knew pretty early on from this list that the delay couldn t be fixed. Perhaps I m a
        Message 3 of 23 , Aug 2 8:47 AM
        • 0 Attachment
          Thus spake Ben Schmidt [08/02/08 @ 11.02.24 +1000]:
          > > If somebody then told be the reason why this happens I would probably go
          > > "aha" and forget about the delay.
          > > Also, as gmn mentioned, opening a new window can take a lot longer than .4
          > > s on older hardware (something that will make less and less of a difference
          > > as time passes and people upgrade, but...).

          Hmmm... well, I certainly don't just forget about the delay, and I knew pretty early on from this list that the delay couldn't be fixed. Perhaps I'm a special case because of older hardware. The delay, for instance, can be up to 2.5 seconds here, and is never less than about 1.5. But with quickstart: snappy!

          (Side note: I think that knowing that nothing can be done about some negative aspect of a program is more conducive to giving up on it, not less so. If I know that work is being done and eventually it will improve, I'm more likely to stick it out. Case in point: the slow rendering in MacVim. I know people are working on a fast one, so that makes it worthwhile to stick with MacVim [even if there weren't other good reasons to stick with it].)

          > I agree that it really needs to be completely transparent and with no
          > side effects if it is to be enabled by default.

          I agree too, especially if it's mainly people like me with rusty G4's who hate the lag. (That said, rusty G4's can still run TextWrangler with zero delays. And how come Carbon Vim runs with no lags?).

          > 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 notice an increase in snappiness when I move my ~/.vim stuff out of the way. But I don't have much in there besides colorschemes and NERDTree.

          > 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.

          I don't see the benefit of this. It's the lag that's annoying, and it doesn't get any shorter when one is notified that a lag is underway. I don't think I've ever wondered whether I *really* pressed cmd-N. NeoOffice, for instance, has a splash screen with a progress bar inside of it, and it's sluggishness is no more tolerable for it.

          Besides, we *do* get visual notification that cmd-N has been pressed: the word "File" in the menubar gets highlighted in blue (or "graphite", if that's your pref).

          Quickstart-enabled MacVim seems to solve the problem nicely, and will be even better when the little issues get ironed out. If people are really opposed to it lurking there, perhaps it can be a compile-time option.
          -gmn



          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Matt Tolton
          ... I disagree here. I think that it would be a bit odd to have the window jump around/resize after it opened up. I can t think of a single app that I use
          Message 4 of 23 , Aug 2 12:20 PM
          • 0 Attachment
            > 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.

            I disagree here. I think that it would be a bit odd to have the
            window jump around/resize after it opened up. I can't think of a
            single app that I use that does that.

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • dv1445@wayne.edu
            ... I can: MacVim! :) Look at what happens when you go into fullscreen mode. Your starting normal sized MacVim window centers itself on the screen, then
            Message 5 of 23 , Aug 2 1:42 PM
            • 0 Attachment
              Thus spake Matt Tolton [08/02/08 @ 12.20.48 -0700]:
              >
              > > 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.
              >
              > I disagree here. I think that it would be a bit odd to have the
              > window jump around/resize after it opened up. I can't think of a
              > single app that I use that does that.

              I can: MacVim! :)

              Look at what happens when you go into fullscreen mode. Your starting "normal" sized MacVim window centers itself on the screen, then resizes itself to span the screen provided you have fuoptions=maxhorz,maxvert. I agree however that this is odd for a Mac app; it's probably unavoidably built into vim.

              This is not to defend the idea of what amounts to a splash screen shaped liked a MacVim window; in a previous post I said I didn't see the point. But to be picky, MacVim already has jumparounds. :)
              -gmn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Matt Tolton
              ... Actually, I can t duplicate this behavior. I see no jumpiness. I see the screen fade to black, and then the macvim window fades in spread across the
              Message 6 of 23 , Aug 2 2:18 PM
              • 0 Attachment
                > I can: MacVim! :)
                >
                > Look at what happens when you go into fullscreen mode. Your starting "normal" sized MacVim window centers itself on the screen, then resizes itself to span the screen provided you have fuoptions=maxhorz,maxvert. I agree however that this is odd for a Mac app; it's probably unavoidably built into vim.
                >
                > This is not to defend the idea of what amounts to a splash screen shaped liked a MacVim window; in a previous post I said I didn't see the point. But to be picky, MacVim already has jumparounds. :)

                Actually, I can't duplicate this behavior. I see no jumpiness. I see
                the screen fade to black, and then the macvim window fades in spread
                across the entire screen. So...to be picky...my statement stands. :)

                --~--~---------~--~----~------------~-------~--~----~
                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.