If you're talking about the release binary, that has an entire libc (musl) statically linked into it. And all of PCRE2. And all of its Rust dependencies including the entire standard library.
that can be the reason, but it's a very bad example
it's quite unlikely that it would be _that_ much smaller if it had been written in C or C++ with the _exact_ same goals, features etc. in mind.
like grep and ripgrep seem on the surface quite similar (grep something, have multiple different regex engine etc.) but if you go into the details they are quite different (not just because rg has file walking and resolution of gitignore logic build in, but also wrt. goals features of their regex engines, performance goals, terminal syntax highlighting etc.)
ripgrep doesn't do "terminal syntax highlighting." It has some basic support for colors, similar to GNU grep.
GNU grep and ripgrep share a lot of similarities, even beyond superficial ones. There are also some major differences. But I've always said that the venn diagram of GNU grep and ripgrep has a much bigger surface area in their intersection than the area of their symmetric difference.
I don't know the reason, but as having worked in embedded, I worked on a project that had drivers, app logic, filesystem support, TCP stack, and then some more, that fit in less that 64kb of ROM (written in C), without much trouble, 2MB for such a tool seems excessive, would love to see a breakdown of what's in there and how much space it takes up.
ugrep, which is C++ and similar in scope to ripgrep is 0.9 MB on my machine, ripgrep is 4.4 MB and GNU grep us 0.2 MB. They all depend on libc and libpcre2.
Ugrep however depends on libstdc++ and a bunch of libraries for compressed file support (libz,...).
So yeah a bit bloated but we are not at Electron level yet.
If you're talking about the release binary, that has an entire libc (musl) statically linked into it. And all of PCRE2. And all of its Rust dependencies including the entire standard library.
Because generic monomorphization generates a massive amount of machine code.
that can be the reason, but it's a very bad example
it's quite unlikely that it would be _that_ much smaller if it had been written in C or C++ with the _exact_ same goals, features etc. in mind.
like grep and ripgrep seem on the surface quite similar (grep something, have multiple different regex engine etc.) but if you go into the details they are quite different (not just because rg has file walking and resolution of gitignore logic build in, but also wrt. goals features of their regex engines, performance goals, terminal syntax highlighting etc.)
Responding narrowly:
ripgrep doesn't do "terminal syntax highlighting." It has some basic support for colors, similar to GNU grep.
GNU grep and ripgrep share a lot of similarities, even beyond superficial ones. There are also some major differences. But I've always said that the venn diagram of GNU grep and ripgrep has a much bigger surface area in their intersection than the area of their symmetric difference.
I don't know the reason, but as having worked in embedded, I worked on a project that had drivers, app logic, filesystem support, TCP stack, and then some more, that fit in less that 64kb of ROM (written in C), without much trouble, 2MB for such a tool seems excessive, would love to see a breakdown of what's in there and how much space it takes up.
1 reply →
ugrep, which is C++ and similar in scope to ripgrep is 0.9 MB on my machine, ripgrep is 4.4 MB and GNU grep us 0.2 MB. They all depend on libc and libpcre2.
Ugrep however depends on libstdc++ and a bunch of libraries for compressed file support (libz,...).
So yeah a bit bloated but we are not at Electron level yet.
8 replies →
Is that a lot for an application that does what it does?