quoted

Calling the function "seq_putc" will be more efficient than "seq_printf"
in this case because of the following reasons.

1. How does the distribution look like for supported processor architectures
   where the data transfer for bytes (as a function call parameter)
   is faster than for (string) pointers?

How would I know?

How many processor architecture characteristics do you know already?

* Is a string pointer often longer than a byte?

* I imagine that it can become also interesting to check byte level data access
  under constraints of machine word sizes and alignment.

I would assume that _you_ did some measurements here;

How much would you trust in any concrete numbers I could present
for this use case?

Do you give more trust to a reference testing platform?

I could easily claim that seq_printf() is more efficient than
seq_putc(), and won't apply your patch.

This is also possible in principle.

So _you_ have to prove that your patch is more efficient.

How many results would we like to clarify from various hardware
and software combinations?

quoted

2. Did anybody measure already how many the execution times can vary
   for these functions?

Probably not.

Thanks for this information.

How important are the mentioned functions for you within the Linux
programming interface so far?

Unless _you_ prove that _your_ patch is more efficient it won't get applied.

Which data would you accept as a "prove" in this case?

quoted

   Where do you get doubts about its efficiency for the data processing
   of a single character?

Because it's being called at the end of a function calling seq_printf() already.

Interesting view …

So exchanging a single call is probably not helping anything,
as the compiler will optimize it anyway.

How common is the discussed software transformation between implementations
for optimising compilers?

Case in point: with your patch the x86_64 compiler generates nearly
identical code for driver/md/raid1.c, but with one instruction _more_
after your patch has been applied.

Which software versions and command parameters did you try out
for this information (from an unspecified run time environment)?

So it's not immediately obvious that your patch is an improvement.

I agree that there are system properties and constraints which can be
considered further.

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html