[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rm improvements from next rebased and pulled onto master
From: |
Jim Meyering |
Subject: |
Re: rm improvements from next rebased and pulled onto master |
Date: |
Sun, 13 Sep 2009 11:59:54 +0200 |
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