On Sun, Aug 10, 2014 at 05:29:53PM +0200, Jean-Pierre André wrote:
> 
> For a better way you would have to identify which is the dll
> which compresses , and submit compression tasks with some
> control over the durations.
> 

RtlCompressBuffer() in ntdll.dll can do LZNT1 compression, which I think is the
same as NTFS compression.  But I wouldn't be surprised if there is actually
another implementation in Microsoft's NTFS driver, which would be inaccessible.
But either way, simply copying files to a NTFS volume is probably good enough
for approximate benchmarking; that's what I was doing with NTFS-3g, after all.

> I had analyzed the difference of results, and I was surprised
> to find that the full length of the matching string was not
> always used (such as found a matching string at some position
> with a matching length of 20, but only used a length of 12
> and the next match not being better than the expected 8 bytes),
> and there does not appear to be a fixed maximum length
> (when all bytes are the same, the matching length is 4095
> as would be expected).
> 
> They probably bargained the duration against the compression
> rate.

This is strange.  If the algorithm does the work to find a match at some
position, it should at least extend it to its full length.  Although a
non-greedy parser will not necessarily choose that full length, it's unexpected
that the algorithm would actually choose a sequence of matches that is *worse*
than that which a greedy parser would choose.  Is it possible that the length 12
match was less distant than the length 20 match?  If it was, then this would be
an expected result of an incomplete search using hash chains.

Regardless, it's probably possible to implement something that beats the
Microsoft implementation (and I have done this for the XPRESS-Huffman and LZX
algorithms), so I personally wouldn't read too much into how they might be doing
things.

Eric

------------------------------------------------------------------------------
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel

Reply via email to