I have an old 256mb usb drive that I'm using as a place to store text files. Scratch notes, links, todo lists, and a personal journal logfile.
I installed vim onto the drive in order to always have a decent text editor, even if I'm switching between computers, quickly editing something on someone else's machine, etc.
I'm not worried about hitting the drive's capacity any time soon: the vim install directory itself takes up more space than all the other text, and vim's pretty small.
But if I was to somehow fill the thing with 2 million or so characters of text, what could I safely delete from the vim install directory to clear up some space?
(Of course this isn't an urgent question, just a fun exercise in minimalism.)
If you want absolute minimalism, you can delete everything and just keep vim.exe (and any required DLLs). You can also reduce vim.exe's size from 1.6 MB to 0.8 MB by using UPX. If you want to reduce vim.exe's size further, compile it yourself removing any flags that you don't need.
You can additionally include your .vimrc, some syntax files, your favourite plugins, etc. The size of this depends on you.
So theoretically you could get your vim installation below 0.8 MB.
I'd start by removing syntax, filetype, and compiler plugins you never intend to use. All the colorschemes could also go, to be replaced with just the one you use (if any).
Assuming you are on Windows, you are going to notice that installation from vim.org uses around 30 mb, which leaves space for plenty text.
If you still believe it is necessary to have Vim use less space, you could try the portable version from PortableApps, which is very stable and uses ~15 mb.
Edit:
Actually the latest gVim Portable (7.4) doesn't save much space. The ~15 mb mentioned refers to version 7.3, which was compiled with a reduced set of features (e.g.: -perl/dyn).
Instead of deleting files as filetype plugins and colorschemes, which are usually very small, you should consider compile Vim enabling only the features you actually use. There are a large number of such features, as can be seem with :version command.
Related
As a developer working with several languages, I notice that in most modern languages, dependencies metadata files can change a lot.
For instance, in NodeJS (which in my opinion is the worst when it comes to package management), a change of dependencies or in the version of NPM (respectively yarn) version can lead to huge changes in package-lock.json (respectively yarn.lock), sometimes with tens of thousands of modified lines.
In Golang for instance, this would be go.sum which can have important changes (in smaller magnitude when compared to Node of course) when modifying dependencies or running go mod tidy at times.
Would it be more efficient to track these dependencies files with git-lfs? Is there a reason not to do it?
Even if they are text files, I know that it is advised to push SVG files with git-lfs, because they are mostly generated files and their diff has no reason to be small when regenerating them after a change.
Are there studies about what language and what size/age of a project that makes git-lfs become profitable?
Would it be more efficient to track these dependencies files with git-lfs?
Git does a pretty good job at compressing text files, so initially you probably wouldn't see much gains. If the file gets heavily modified often, then over time the total cloneable repo size would increase by less if you use Git LFS, but it may not be worth it compared to the total repo size increases, which could make the size savings negligible as a percentage. The primary use case for LFS is largish binary files that change often.
Is there a reason not to do it?
If you aren't already using Git LFS, I wouldn't recommend starting for this reason. Also, AFAIK there isn't native built in support for diffing versions of files stored in LFS, though workarounds exist. If you often find yourself diffing the files you are considering moving into LFS, the nominal storage size gain may not be worth it.
On my Windows 10 machine it's 3.5GG. What is it storing? How can I trim it down?
It is storing all the downloaded crates you have used, their binaries, the index of registries, etc. It is going to take a lot of space and will keep increasing.
You can safely remove .cargo/registry/ (if you remove the entire folder, you will lose installed binaries and your Cargo configuration if you had one). Afterwards, everything you use again will be downloaded and it will start growing back. It is a common way of getting rid of very old dependencies you are not using anymore.
When doing a fresh install of Haskell Stack through the install script from here:
wget -qO- https://get.haskellstack.org/ | sh
Followed by:
stack setup
you will end up with a $HOME/.stack/ directory of 1.5 GB size (from just a 120+ MB download). Further if you run:
stack update
the size increases to 2.5 GB.
I am used to Java which is usually considered large/big (covers pretty much everything and has deprecated alternatives for backwards compatibility), but as a comparison: an IDE including a JDK, a stand alone JDK, and the JDK source is probably around 1.5 GB in size.
On the other hand, that Haskell which is a "small beautiful" language (from what I have heard and read, this is probably referring mostly to the syntax and semantics, but still), is that large/big, seems strange to me.
Why is it so big (is it related to this question?)?
Is this size normal or have I installed something extra?
If there are several (4?, 5?) flavors of everything, then can I remove all but one?
Are some of the data cache/temporary that can be removed?
The largest directories are: .stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2 (1.3 GB) and .stack/indices/Hackage (980 MB). I assume the first one are installed packages (and related to stack setup) and the latter is some index over the Hackage package archive (and related to stack update)? Can these be reduced (as above in 3 or grabbing needed Hackage information online)?
As you can probably see by inspection, it is a combination of:
three flavors (static, dynamic, and profiled) of the GHC runtime (about 400 megs total) and the core GHC libraries (another 700 megs total) plus 100 megs of interface files and another 200 megs of documentation and 120 megs of compressed source (1.5 gigs total, all under programs/x86_64-linux/ghc-8.2.2* or similar)
two identical copies of the uncompressed Hackage index 00-index.tar and 01-index.tar, each containing the .cabal file for every version of every package ever published in the Hackage database, each about 457 megs, plus a few other files to bring the total up to 1.0 gigs
The first of these is installed when you run stack setup; the second when you run stack update.
To answer your questions:
It's so big because clearly no one has made any effort to make it smaller, as evidenced by the whole 00-index.tar, 00-index.tar.gz, and 01-index.tar situation.
That's a normal size for a minimum install.
You can remove the profile versions (the *_p.a files) if you never want to compile a program with profiling. I haven't tested this extensively, but it seems to work. I guess this'll save you around 800 megs. You can also remove the static versions (all *.a files) if you only want to dynamically link programs (i.e., using ghc -dynamic). Again, I haven't tested this extensively, but it seems to work. Removing the dynamic versions would be very difficult -- you'd have to find a way to remove only those *.so files that GHC itself doesn't need, and anything you did remove would no longer be loadable in the interpreter.
Several things are cached and you can remove them. For example, you can remove 00-index.tar and 00-index.tar.gz (saving about half a gigabyte), and Stack seems to run fine. It'll recreate them the next time you run stack update, though. I don't think this is documented anywhere, so it'll be a lot of trial and error determining what can be safely removed.
I think this question has already been covered above.
A propos of nothing, the other day, I saw a good deal on some 3-terabyte drives, and in my excitement I ordered two before realizing I didn't really have anything to put on them. It kind of puts a few gigabytes in perspective, doesn't it?
I guess I wouldn't expend a lot of effort trying to trim down your .stack directory, at least on a beefy desktop machine. If you're working on a laptop with a relatively small SSD, think about maybe putting your .stack directory on a filesystem that supports transparent compression (e.g., Btrfs), if you think it's likely to get out of hand.
I opened a PDF file in vim which was about 4MB and it opened it at the blink of eye. I was amazed at the speed. So I tried the same in notepad and it crashed. I tried in notepad++, it took time.
Does anyone knows how vim handles this scenarios ? What makes reading files in vim so fast ?
Vim reads the whole file into an internal buffer on opening, so this all depends on your (virtual) memory and overall computer performance. Some disk editors only read in (viewed) parts of the file dynamically, and thereby obtain even greater performance.
On todays hardware, 4 MB is nothing. You can still drag down Vim with files of 100s of MB, especially if long lines or syntax highlighting is involved.
Other editors should not have a problem with 4 MB, neither. But PDF is not a text format, it's binary, so that might have confused some editors or taken them a long time to figure out what it's about.
The LargeFile plugin is worth mentioning here.
While searching for my python completion nirvana in vim, I have come to really love <C-x> <C-i>: "keywords in the current and included files". This almost always gets me a long nasty name from another module completed, which is great.
(Omni-completion is obviously better when it works, but too often it reports it can't find any matches. Ok, Python isn't Java, I get it)
The only problem with this multi-file completion is it's very slow: on my netbook, a file with a reasonable set of imports can take up to 4 or 5 seconds to parse every time I hit <C-x> <C-i>. It seems to load every imported file every time I hit <C-x> <C-i>. Is there any way to cache the files or speed up this process? Would using tag completion be faster?
It is quite possible that this process takes some time if you're working on projects with multiple source files (vim needs to parse all included source files to find more included source files and to build the word list.) You could use tag-completion, which uses the output of ctags to do almost the same, but you'd need to run a few tests to tell the speed difference.
I personally use complete completion (<C-P> or <C-N> in insert mode.) By default, it matches all words in all buffers (even buffers that have been unloaded, i.e. files that have been closed), but is really fast. I found that the completion works quite accurately nonetheless, even if you activate it after 2-3 characters.