Slow after e838867 #11

Closed
moll opened this Issue Nov 14, 2012 · 5 comments

Comments

Projects
None yet
3 participants
@moll

moll commented Nov 14, 2012

I'm not sure if this is by design (hopefully not!) because it actually does more, but after e838867, Vim's startup and Ruby file opening went from ~300ms to 1400ms.

I've got a godly scientific benchmark to present:

# Before e838867:
% time vim ~/Documents/monday/app/config/application.rb -c :quit
vim ~/Documents/monday/app/config/application.rb -c :quit  0.22s user 0.04s system 85% cpu 0.303 total
# After e838867:
% time vim ~/Documents/monday/app/config/application.rb -c :quit
vim ~/Documents/monday/app/config/application.rb -c :quit  1.17s user 0.15s system 95% cpu 1.394 total
@tpope

This comment has been minimized.

Show comment Hide comment
@tpope

tpope Nov 17, 2012

Owner

The first time you load a Ruby file from a bundler project, bundler.vim tries to find the location of all bundled gems, so it can put them in 'path' and 'tags'. It attempts first using a quick hack based on $GEM_PATH and Gemfile.lock, and if that fails, it asks bundler itself to do it, which takes a bit longer. That's the delay you're seeing.

The fix I'd prefer to see is improve the hack. Here's some cases that hack currently can't cope with:

  • $GEM_PATH is not set (e.g., pretty much everywhere but rvm).
  • Gems bundled in vendor/
  • Gems pointed at Git.
  • Gems pointed at a hardcoded path.

Which of these applies to you, if any?

Owner

tpope commented Nov 17, 2012

The first time you load a Ruby file from a bundler project, bundler.vim tries to find the location of all bundled gems, so it can put them in 'path' and 'tags'. It attempts first using a quick hack based on $GEM_PATH and Gemfile.lock, and if that fails, it asks bundler itself to do it, which takes a bit longer. That's the delay you're seeing.

The fix I'd prefer to see is improve the hack. Here's some cases that hack currently can't cope with:

  • $GEM_PATH is not set (e.g., pretty much everywhere but rvm).
  • Gems bundled in vendor/
  • Gems pointed at Git.
  • Gems pointed at a hardcoded path.

Which of these applies to you, if any?

@moll

This comment has been minimized.

Show comment Hide comment
@moll

moll Nov 18, 2012

Lack of GEM_PATH and Git repos in Gemfile definitely apply to me.

Hmm, I'm using vim-bundler primarily for its convenient :Bopen command, which I also don't use very often.
'path' and 'tags' I don't care for at all.

One work-around I'd think to speed things up would be to provide a way to disable 'path'/'tags' filling and delay all that slow initialization till :Bopen is first used.

moll commented Nov 18, 2012

Lack of GEM_PATH and Git repos in Gemfile definitely apply to me.

Hmm, I'm using vim-bundler primarily for its convenient :Bopen command, which I also don't use very often.
'path' and 'tags' I don't care for at all.

One work-around I'd think to speed things up would be to provide a way to disable 'path'/'tags' filling and delay all that slow initialization till :Bopen is first used.

@tpope tpope closed this in b2cad30 Nov 19, 2012

@tpope

This comment has been minimized.

Show comment Hide comment
@tpope

tpope Nov 19, 2012

Owner

I had already fixed the $GEM_PATH issue and forgotten about it. My latest commit fixes Git gems and path gems. Let me know if it's still an issue.

I save options (particularly to disable behavior) for a last resort. People tend to set them without understanding the implications, or worse, copy and paste other people's vimrcs without even realizing what all they're setting.

Owner

tpope commented Nov 19, 2012

I had already fixed the $GEM_PATH issue and forgotten about it. My latest commit fixes Git gems and path gems. Let me know if it's still an issue.

I save options (particularly to disable behavior) for a last resort. People tend to set them without understanding the implications, or worse, copy and paste other people's vimrcs without even realizing what all they're setting.

@dyfrgi

This comment has been minimized.

Show comment Hide comment
@dyfrgi

dyfrgi Nov 28, 2012

vim-bundler currently increases my load times by 800ms. I find that there is a 600ms difference between 7e65144 and e838867 (which is the next one, referenced by the reporter here).

Explicitly setting GEM_PATH as reported by bundle exec env actually makes things much worse, taking a full 1800ms to load.

I don't have GEM_PATH set typically, as I use rbenv.
I have gems in git.
It appears I have gems in plugins (who knew! I just started at a new place)
No hardcoded ones though!

Removing the plugins doesn't help. So, the problem is that bundle show is slow, ultimately? If I make that fast, vim-bundler should also be fast?

For now I'm using 7e65144, but I'm interested in helping fix this.

dyfrgi commented Nov 28, 2012

vim-bundler currently increases my load times by 800ms. I find that there is a 600ms difference between 7e65144 and e838867 (which is the next one, referenced by the reporter here).

Explicitly setting GEM_PATH as reported by bundle exec env actually makes things much worse, taking a full 1800ms to load.

I don't have GEM_PATH set typically, as I use rbenv.
I have gems in git.
It appears I have gems in plugins (who knew! I just started at a new place)
No hardcoded ones though!

Removing the plugins doesn't help. So, the problem is that bundle show is slow, ultimately? If I make that fast, vim-bundler should also be fast?

For now I'm using 7e65144, but I'm interested in helping fix this.

@tpope

This comment has been minimized.

Show comment Hide comment
@tpope

tpope Nov 28, 2012

Owner

Yes, the underlying problem is that bundler is slow, and fixing that would be wonderful. But failing that, the best thing to do is figure out why bundler.vim is having trouble parsing your Gemfile.lock. The most straightforward way to do this is to try deleting more and more from your Gemfile (rerunning bundle each time) until things get quick, and figure out what gem is the tipping point. If you figure out what's making it slow, I imagine I can figure how to make it quick.

Note that using 7e65144 breaks pretty much everything but the syntax highlighting.

Owner

tpope commented Nov 28, 2012

Yes, the underlying problem is that bundler is slow, and fixing that would be wonderful. But failing that, the best thing to do is figure out why bundler.vim is having trouble parsing your Gemfile.lock. The most straightforward way to do this is to try deleting more and more from your Gemfile (rerunning bundle each time) until things get quick, and figure out what gem is the tipping point. If you figure out what's making it slow, I imagine I can figure how to make it quick.

Note that using 7e65144 breaks pretty much everything but the syntax highlighting.

tpope added a commit that referenced this issue Jan 24, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment