Re: rm improvements from next rebased and pulled onto master

[Jim Meyering]

Ralf Wildenhues wrote:
> * Jim Meyering wrote on Sun, Sep 13, 2009 at 11:17:50AM CEST:
>> Ralf Wildenhues wrote:
>> > Jim Meyering writes:
>> >> Here's post-7.6 NEWS so far:
>> >>     rm -r deletes deep hierarchies more efficiently.  Before, it took 
>> >> O(N^2)
>> >>     time, now it takes O(N).
>> >
>> > What is N?  The number of files removed, the number of directories removed,
>> > the maximal subdirectory depth?
>
>> It's the latter, as implied by the preceding "deep hierarchies".
>
> Thanks.  I suggest adding
>   , with N the subdirectory depth.
>
> to the NEWS entry.  Still two lines, but much more precise now.  :-)

alright, alright ;-)
I've made a minor correction to the following entry, too:

>From 21b617b78b5f53c1b6e1447f1709b1c2aa9f466f Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Sun, 13 Sep 2009 11:48:03 +0200
Subject: [PATCH] doc: improve NEWS

* NEWS (rm -r, without -f): Mention that the N in "O(N)" represents
hierarchy depth.  Suggested by Ralf Wildenhues.
(rm -r, standards conformance): Make wording more accurate.
---
 NEWS |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/NEWS b/NEWS
index b3c6c8c..ec41ca7 100644
--- a/NEWS
+++ b/NEWS
@@ -14,14 +14,14 @@ GNU coreutils NEWS                                    -*- 
outline -*-
   cases, and slightly slower (20%) in at least one pathological case.

   rm -r deletes deep hierarchies more efficiently.  Before, it took O(N^2)
-  time, now it takes O(N).  However, this improvement is not as pronounced
-  as might be expected for very deep trees, because prior to this change, for
-  any relative name length longer than 8KiB, rm -r would sacrifice official
-  conformance to avoid the disproportionate O(N^2) performance penalty.
-  Leading to another improvement:
+  time, now it takes O(N), where N is the depth of the hierarchy.  However,
+  this improvement is not as pronounced as might be expected for very
+  deep trees, because prior to this change, for any relative name length
+  longer than 8KiB, rm -r would sacrifice official conformance to avoid the
+  disproportionate O(N^2) performance penalty.  Leading to another improvement:

   rm -r is now slightly more standards-conformant when operating on
-  write-protected relative file names longer than 8KiB.
+  write-protected files with relative names longer than 8KiB.


 * Noteworthy changes in release 7.6 (2009-09-11) [stable]
--
1.6.5.rc0.190.g15871