bin/96393: [libz] [patch] assembler implementations for libz on i386

[Mikhail T.]

неділя 20 січень 2008, David Schultz, Ви написали:
= Hmm, sorry, but I don't think we should be in the business of
= supporting complex optimizations to vendor code that the vendor
= himself won't support. It would take a substantial amount of
= effort to verify that the changes are (a) correct and (b) faster,
= and things could break in subsequent imports.

Well, we've done it with gzip itself (when it was a standalone executable, 
rather than libz's client). We are doing it with Sun's msun. It would not be 
without precedent and the libz's build procedure (which we are not using) 
allows for it -- we don't even need to modify the "vendor's branch".

The savings are substantial, but they require changes to the build process, 
which is something, the vendor (a single person, really) is understandibly 
hesitant to undertake.

Yes, port is a possibility and something I can do myself, but "out-of-the-box" 
performance improvement seems a worthy goal to me. Libz is not a port, but 
part of the src-tree -- offering to replace it with a "better libz" (of the 
same version!) begs the question of why it is not done by default...

	-mi