MIME-Version: 1.0
References: <20230127155135.27153-1-andriy.shevchenko@linux.intel.com> <a903947619f94dfa88d3dd147b7a5e95@AcuMS.aculab.com>
In-Reply-To: <a903947619f94dfa88d3dd147b7a5e95@AcuMS.aculab.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Sat, 28 Jan 2023 21:54:44 +0200
Message-ID: <CAHp75VcZgkuOA3pSrg7cN36EAB4Y0jV2xFNfj-sGp_C17J2yAQ@mail.gmail.com>
Subject: Re: [PATCH v1 1/1] lib/string: Use strchr() in strpbrk()
To:     David Laight <David.Laight@aculab.com>
Cc:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Kees Cook <keescook@chromium.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andy Shevchenko <andy@kernel.org>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Jan 28, 2023 at 4:51 PM David Laight <David.Laight@aculab.com> wrote:
>
> From: Andy Shevchenko
> > Sent: 27 January 2023 15:52
> >
> > Use strchr() instead of open coding it as it's done elsewhere in
> > the same file. Either we will have similar to what it was or possibly
> > better performance in case architecture implements its own strchr().
>
> Except that you get a whole load of calls to strchr() for (typically)
> very few characters.
> So the cost of the calls dominates, anything that tries to speed up
> strchr() for long strings will also slow things down.

Hmm... I haven't seen the calls, I assume gcc simply inlined a copy of that.

...

> Although I very much doubt strpbrk() is used anywhere where
> performance matters.

strsep()/strspn() are the users.

-- 
With Best Regards,
Andy Shevchenko