[Zlib-devel] [PING] Improve longest_match performance

[John Reiser]

On 07/24/2012, Andreas Krebbel wrote:

> any comments regarding this one?
> 
> http://mail.madler.net/pipermail/zlib-devel_madler.net/2012-June/002907.html

These changes in the width of variables which contribute to indexing
of arrays:
-----
+    uLong cur_match = pcur_match; /* extend to pointer width */

+    uLong wmask = s->w_mask;
-----
should use 'ptrdiff_t' instead.  It ought to take only a minor increase
in intelligence for the compiler to do such a widening automatically,
because all uses are associated with array indexing, and a machine with
64-bit addresses often charges a high price for indexing by a 32-bit quantity.


These changes in the width of scan_start, scan_end, scan_end1:
-----
-    register ush scan_start = *(ushf*)scan;
-    register ush scan_end   = *(ushf*)(scan+best_len-1);
+    register uInt scan_start = *(ushf*)scan;
+    register uInt scan_end   = *(ushf*)(scan+best_len-1);
 #else
     register Bytef *strend = s->window + s->strstart + MAX_MATCH;
-    register Byte scan_end1  = scan[best_len-1];
-    register Byte scan_end   = scan[best_len];
+    register uInt scan_end1  = scan[best_len-1];
+    register uInt scan_end   = scan[best_len];
-----
are an indictment of the compiler, so you should demand better
from its maintainers.  All uses depend on only the width in memory,
such as:
-----
        if (match[best_len]   != scan_end  ||
            match[best_len-1] != scan_end1 ||
-----
thus any widening and narrowing are the compiler's fault alone.
Also, widening these in the source code likely will hurt performance
for lower-end compilers (in particular, many instances of gcc on
[or for] i386, i486, other low-end processors) which tend to believe
the declarations, then skimp on range analysis.

--