Hi there,
I just stumbled on this by accidentally redirecting the output of a
colored grep invocation to a file like so:
$ grep --color=always . /sys/kernel/mm/transparent_hugepage/*
>thp-status.txt 2>/dev/null
# for convenience the 1st line of actual uncolored output
/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise
[madvise] never
Subsequently opening said file in vim I was overwhelmed with escape
sequences. From the looks of it every character in the match gets its
very own color escape sequence as opposed to the string indicating the
path to the file (everything before ':') which is actually kind of
readable b/c it starts with only one escape sequence which gets reset
just before ':'.
Now I know that this is not really how one is supposed to use the
program and its output but it does show that the way grep works when
coloring the match is rather inefficient. As I said, I only discovered
this by accident, as in, otherwise I hadn't noticed any performance
issues or other ill-effects. The interesting part is that this way the
color escapes outweigh the actual payload text quite substantially:
$ du -b grep*
2471 grep-color-always.txt
359 grep-color-auto.txt
This the same output as above, the names should say it all. That's just
shy of factor 7! I think that is quite some overhead for what the actual
purpose is. Now I don't necessarily agree with "benchmarking" terminal
emulators but did read a little about it. And maybe I just don't have a
brutal enough use case to make this an actual performance issue on my
hardware. But I believe fixing this might just result in some
improvements in that area, FWIW.
I am using GNU grep 3.11, which seems to be the current stable release,
on the current Ubuntu 24.04 LTS release. So maybe this has been
addressed in a later devel version? A cursory search for the issue
turned up empty though. That's why I would rather avoid compiling from
source for now, unless of course for testing a possible fix. Again, I
don't *need* a fix and would be happy to wait another year for the next
Ubuntu LTS, given the non-noticeable impact on my end.
So is this something that cannot be done any other way b/c of the way
matching works - as in: "if it can't be done elegantly use brute force"?
Or could this be classified as an actual bug, albeit a low priority one?
Peter White
