Announcement

Collapse
No announcement yet.

Grep 2.21 Brings Performance Improvements

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Grep 2.21 Brings Performance Improvements

    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

  • #2
    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!

    Comment


    • #3
      Originally posted by phoronix View Post
      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?

      Comment


      • #4
        Originally posted by Stunts View Post
        ...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.

        Comment


        • #5
          Originally posted by kaprikawn View Post
          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. =-)

          Comment


          • #6
            Originally posted by Stunts View Post
            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

            Comment


            • #7
              Originally posted by Nille View Post
              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.

              Comment


              • #8
                Originally posted by Stunts View Post
                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.

                Comment


                • #9
                  Originally posted by Gusar View Post
                  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.

                  Comment

                  Working...
                  X