[PATCH] fs: seq_file: optimize seq_pad()

[PATCH] fs: seq_file: optimize seq_pad()

[Dmitry Voytik]

Use seq_putc() instead of seq_printf() in seq_pad() because the
former is faster.

Signed-off-by: Dmitry Voytik <voytikd@gmail.com>
---
 fs/seq_file.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/seq_file.c b/fs/seq_file.c
index 3857b72..fef338e 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -787,8 +787,10 @@ EXPORT_SYMBOL(seq_write);
 void seq_pad(struct seq_file *m, char c)
 {
 	int size = m->pad_until - m->count;
-	if (size > 0)
-		seq_printf(m, "%*s", size, "");
+
+	while (size-- > 0)
+		if (unlikely(seq_putc(m, ' ')))
+			return;
 	if (c)
 		seq_putc(m, c);
 }
-- 
1.9.1

Re: [PATCH] fs: seq_file: optimize seq_pad()

[Al Viro]

On Wed, Sep 10, 2014 at 01:20:19PM +0400, Dmitry Voytik wrote:
> Use seq_putc() instead of seq_printf() in seq_pad() because the
> former is faster.

_Solitary_ seq_putc() is certainly going to be faster, but that loop...
Do you have profiling results, or is it just an apriori "printf must
be sloooowwww"?

Re: [PATCH] fs: seq_file: optimize seq_pad()

[Dmitry Voytik]

On Wed, Sep 10, 2014 at 5:21 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Wed, Sep 10, 2014 at 01:20:19PM +0400, Dmitry Voytik wrote:
>> Use seq_putc() instead of seq_printf() in seq_pad() because the
>> former is faster.
>
> _Solitary_ seq_putc() is certainly going to be faster, but that loop...
> Do you have profiling results, or is it just an apriori "printf must
> be sloooowwww"?

My fail, sorry. The commit message is little bit wrong. I meant that simple
looping of seq_putc() is faster than seq_printf(). I haven't done profilings.
I just realized that seq_printf() is more complex than simple loop
with seq_putc()
(no need to decode format string as in vsnprintf(), etc).
If I resend the patch with the following commit message:

Use a simple loop with seq_putc() instead of seq_printf() in seq_pad() as
this approach is faster due to less complexity in terms of machine cycles.

Would be it Okay?
Thank you for reviewing.

-- 
Best Regards,
Dmitry Voytik.
voytikd@gmail.com