Re: [PATCH v2 3/2] lib/uuid.c: Silence an unchecked return value warning

["George Spelvin" <linux@sciencehorizons.net>]

Andy Shevchenko wrote:

> ^^^^ Something wrong with mail configuration?

Oops, sorry, I forgot to delete the header.

> On Sun, 2016-06-05 at 15:25 -0400, George Spelvin wrote:
>> It's also faster, as hex_to_bin() *is* inlined within hex2bin()
>> (if you compile with -O).

> To be sure it faster we need the measurements. Sometimes it's not
> obvious.

You're right that sometimes measurements show surprising results.
But do you want to bet on it?  :-)

If speed were a primary goal, I'd want to be sure.

But as you pointed out, this is not hot-path code and speed is *not*
a primary goal.  Being off the hot path also makes benchmarking
more annoying, as it's hard to define realistic test conditions.
(Code resident in L2 but not in L1?)

So I think it's reasonable in this case to estimate rather than waste
effort striving for certainty.  Performing the same basic operations in
the same order, but with shorter code and fewer jumps, it's hard not to
be faster.

It might be measurably faster, or it might be an insignificant change
that's not measurable, but barring some bizarre alignment or cache
aliasing effect, the chance of it being *slower* is negligible.

Speaking pedantically, you're right.  But as a practical matter, it's
very unlikely, and what makes it truly insignificant is that it's not
really a problem even if I'm wrong and the code *is* slower.

As you said, size is more important than speed, and I did, at your
request, benchmark that.  I'm just trying to make the sort of changes
that improve *both*.

If you have a realistic concern that the patches degrade speed, I can
put in a few hours of work to put the different versions into a test
harness and measure it accurately.

But if this is just a pro forma observation that estimates aren't
perfectly reliable, it's not worth the effort.