On Thu, Sep 11, 2025 at 8:50 AM Caleb Sander Mateos <csander@xxxxxxxxxxxxxxx> wrote: > > On Thu, Sep 11, 2025 at 12:33 AM Guan-Chun Wu <409411716@xxxxxxxxxxxxxx> wrote: > > > > From: Kuan-Wei Chiu <visitorckw@xxxxxxxxx> > > > > The base64 decoder previously relied on strchr() to locate each > > character in the base64 table. In the worst case, this requires > > scanning all 64 entries, and even with bitwise tricks or word-sized > > comparisons, still needs up to 8 checks. > > > > Introduce a small helper function that maps input characters directly > > to their position in the base64 table. This reduces the maximum number > > of comparisons to 5, improving decoding efficiency while keeping the > > logic straightforward. > > > > Benchmarks on x86_64 (Intel Core i7-10700 @ 2.90GHz, averaged > > over 1000 runs, tested with KUnit): > > > > Decode: > > - 64B input: avg ~1530ns -> ~126ns (~12x faster) > > - 1KB input: avg ~27726ns -> ~2003ns (~14x faster) > > > > Signed-off-by: Kuan-Wei Chiu <visitorckw@xxxxxxxxx> > > Co-developed-by: Guan-Chun Wu <409411716@xxxxxxxxxxxxxx> > > Signed-off-by: Guan-Chun Wu <409411716@xxxxxxxxxxxxxx> > > --- > > lib/base64.c | 17 ++++++++++++++++- > > 1 file changed, 16 insertions(+), 1 deletion(-) > > > > diff --git a/lib/base64.c b/lib/base64.c > > index b736a7a43..9416bded2 100644 > > --- a/lib/base64.c > > +++ b/lib/base64.c > > @@ -18,6 +18,21 @@ > > static const char base64_table[65] = > > "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; > > Does base64_table still need to be NUL-terminated? > > > > > +static inline const char *find_chr(const char *base64_table, char ch) > > Don't see a need to pass in base64_table, the function could just > access the global variable directly. Never mind, I see the following patches pass in different base64_table values.
