> Hi Chris!
>
> On Mi, 23 Dez 2009, Chris Jones wrote:
>
> > Where slow is concerned, the feature might be that Bram does not
> > favor the idea of turning vim into an IDE, or so I heard.. All the
> > same, even if vimscript is not C, I am quite shocked at how long it
> > takes to load a 100-file or so directory.. feels like minutes and
> > must be something like five seconds, on my laptop.
>
> Is that the NERDtree that is so slow?
It's just loading directories. Since I do not see anything remotely
comparable and NERDTree has been around for quite some time, it could be
either some Vim option or other, or else, it's doing some really fancy
stuff with the directories behind the scenes. Something the developer
could enlighten us about.
> I am asking, because a file with several hundreds of lines opens
> nearly instantaneously here. But then, I usually try to avoid loading
> plugins, since I need to work on many different places where often I
> usually only have a vanilla vim available and try not to become
> dependent on plugins.
Which is really the issue with non-trivial plugins. As long as you have
access to a full-blown Vim, I guess this means you'd have to take a
plugin CD along everywhere you travel. Unless you are at secure sites
where they would be very cross indeed if you loaded anything fancy on
one of their computers, that is.
> Though I have had speed problems with vim before. But that was with
> files of several hundred thousands of lines. (At work I need to load a
> lot of large CSV files into a DWH.) And I often find it very
> frustrating that vim is so "slow".
None here, but then I don't manipulate files that large or directory
trees with more than a few thousand files.
> But then I think of the situations, like today, where I needed to
> transform a tab delimited file into a sql insert statements (by the
> use of some regex). This resulted in a file of about 65k lines (about
> 16,000 insert statements). Loading that file into Toad, made it so
> slow, that I couldn't even navigate anymore (Windows complained about
> running out of virtual memory) and when trying to execute it, Toad
> crashed ;) So Vim is certainly capable of handling large files just
> find. I still wish, it could be just a little bit faster ;)
This sounds like something where you don't need to interact with the
process while it's running. Wouldn't it be a case where it's better to
use the usual batch tools such as sed, awk, or even something like ed to
achieve the desired result?
> Having said that, I wonder, whether it would be possible to have
> NERDtree cash its directory listings, so it wouldn't be so time
> consuming to recreate the view. But then I do not know anything about
> Nerdtree either (not even how it is spelled correctly ;)) and maybe it
> does that already…
Still wouldn't address the issue of the initial loading of something as
small as the average linux system's /etc taking about five seconds. Five
seconds is not a lot as compared to what you are doing, but then my
perception is that it's a trivial task that I perform hundreds of times
daily and it response should be instantaneous.
CJ
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment