Grep 2.21 Brings Performance Improvements

[phoronix]

Phoronix: Grep 2.21 Brings Performance Improvements

Grep 2.21 has been released and represents nearly a half-year worth of improvements to this commonly used GNU utility...

http://www.phoronix.com/vr.php?view=MTg0NjI

[kaprikawn]

Oh, if only I could get this at work. If you grep recursively, sometimes it takes ages. But given that we're talking about Aix on a production server, I'll look forward to this when this hits in about 5 years time.

Why my workplace doesn't use Arch on their servers I'll never know!

[Stunts]

Phoronix: Grep 2.21 Brings Performance Improvements

Grep 2.21 has been released and represents nearly a half-year worth of improvements to this commonly used GNU utility...

http://www.phoronix.com/vr.php?view=MTg0NjI

Arch on servers may not be a very good idea due to kernel module loading.
The moment you update your kernel, even if it's just a point release update, you break all external module loading. You have to reboot (or kexec) to get everyting on working order again, which is not ideal on production servers.
That being said, why not just compile grep yourself and use your local binary instead of the global one?

[kaprikawn]

...why not just compile grep yourself and use your local binary instead of the global one?

Because I'd risk being fired. I'd certainly make the Unix admin team's shtlist.

[Stunts]

Because I'd risk being fired. I'd certainly make the Unix admin team's shtlist.

Owo, they do rule with an iron fist!
As a sysadmin myself I don't see a reason not to let other people use their own binaries for whatever task they require... as long as they don't bother other users. But that's just me and I don't manage systems for that many users.

Back on topic, I wonder how much of a difference in performance this really makes... maybe Michael could test it? If I have the time I might try to draw a PTS profile for grep benchmarks. =-)

[Nille]

The moment you update your kernel, even if it's just a point release update, you break all external module loading. You have to reboot (or kexec) to get everyting on working order again, which is not ideal on production servers.

In each Point release are fixes that are back ported to the distribution kernels. So, its doesn't matter you have to reboot or kexec the running kernel in all cases

[Stunts]

In each Point release are fixes that are back ported to the distribution kernels. So, its doesn't matter you have to reboot or kexec the running kernel in all cases

True.
But when you update a kernel in say - ubuntu, after the upgrade process takes place, you system still works 100% (albeit without the fixes and features from the updated), you can still modprobe everything you want and restart any services that require modules (such as NFS server or a PPTP VPN connection).
When you do this with Archlinux, module loading breaks. This means that you you have to restart a service (such as NFS server or a PPTP VPN connection), it won't work until you reboot.

In a desktop machine this is simply annoying, and most times you won't even notice it, but on a production server... that's another story.

[Gusar]

In a desktop machine this is simply annoying, and most times you won't even notice it, but on a production server... that's another story.

On a production server you simply have the linux package in IgnorePkg, and update it manually just before a scheduled reboot. So it's hardly a big deal.

[Stunts]

On a production server you simply have the linux package in IgnorePkg, and update it manually just before a scheduled reboot. So it's hardly a big deal.

Gusar, that is actually quite a good idea!
Stuff that will break without a kernel upgrade on the desktop and require reboots (such as nvidia, mesa, desktop environments, etc...) does not apply to a typical server environment. That might actually work. Other stuff that would concern me would be stuff such as systemd, dbus, glibc... that could eventually be a lot of stuff to keep track of.
But I will keep this in mind during my next experiments.