Forem: Yair Lenga

Optimizing Chained strcmp Calls for Speed and Clarity

Yair Lenga — Tue, 14 Apr 2026 10:35:42 +0000

From memcmp and bloom filters to 4CC encoding for small fixed-length string comparisons

I've been working on an article to describe a small performance issues with a pattern I've seen multiple times - long chain of if statements based on strcmp. This is the equivalent of switch/case on string value (which is not supported in C).

The code implemented critical business logic, based on currency codes (ISO 3-letter code), and an as-of date. Similar to:

bool model_ccy_lookup(const char *s, int asof, struct model_param *param)
{
    // Major Currencies
    if ( strcmp(s, "USD") == 0 || strcmp(s, "EUR") == 0 || ...) {
        ...
    // Asia-Core
    } else if ( strcmp(s, "CNY") == 0 || strcmp(s, "HKD") == 0 || ... ) {
        ...
    } else if ( ... ) {
        ...
    } else {
        ...
    }
}

The code couldn’t be refactored into a different structure (for non-technical reasons), so I had to explore few approaches to keep the existing structure - without rewrite/reshape of the logic. I tried few tings - like memcmp, small filters, and eventually packing the strings into 32-bit values (“4CC”-style) and letting the compiler work with integer compares.

I was able to revise the code into cleaner form, which outperform the original code by 10X. This was achieved with a series of experiments, some of them helped, some of them did not yield improvements, but hinted at other directions.

Full Article: Medium (No Paywall):

Optimizing Chained `strcmp`Calls for Speed and Clarity

The final implementation looks like:

bool model_ccy_lookup(const char *s, int asof, struct model_param *param)
{
    // Major Currencies
    if ( CCY_IN(s, "USD", "EUR", ...) ) {
        ...
    // Asia-Core
    } else if ( CCY_IN(s, "CNY", "HKD", ...) ) {
        ...
    } else if ( ... ) {
        ...
    } else {
        ...
    }
}

And the CCY_IN was implemented as a series of integer compare, using the FourCC encoding = replacing each fixed-size strcmp with a call to CCY_EQ macro:

#define CCY_EQ(x, ccy) (*(int *)x == *(int*) ccy )

I’m also trying a slightly different writing style than usual - a bit more narrative, focusing on the path (including the dead ends), not just the final result.

If you have a few minutes, I’d really appreciate feedback (comment here or on Medium) on two things:

Does the technical content hold up?
Is the presentation clear, or does it feel too long / indirect?

Interested to hear on other ideas/approach for this problem as well.

Safer Casting in C — With Zero Runtime Cost

Yair Lenga — Tue, 07 Apr 2026 07:58:10 +0000

C gives us two types of casting: Implicit casting — happens automatically in expressions and function calls, and Explicit casting — with the cast operator (T) v (e.g. (int) x).

Both are powerful - and both introduce risks - making subtle, hard-to-detect bugs easy to introduce.

I've been looking for safer way to use casts in C, and I came up with simple idea: replace (T) v with function like macros, similar in spirit to SQL's CONVERT(type, value).

A Small Example (same behavior, better readability):

// before, It it:
//     (*((long *) buf)) + 1 OR
//     *((long *) (buf + 1 )) OR
//     *(((long *) buf) + 1)
long p = *(long *) buf + 1;

/* after */
long p = *CAST_PTR1(long *, buf) + 1;

Full Article (Medium - no paywall):

Safer Casting in C — With Zero Runtime Cost

I tried a simple approach: replace (T)v with function-like macros such as CAST_VAL, CAST_PTR, and CAST_PTR1, and UNCONST. The idea isn’t to make C type-safe, but to make casts explicit, structured, and easier to audit. Some basic checks can be enforced at compile time (using gcc/clang extensions), and everything still compiles down to the same code — no runtime cost.

In practice, this shifts casts from “hidden syntax” to something more visible and intentional. For example, separating value casts from pointer casts, and explicitly handling things like removing const, makes questionable conversions stand out immediately in code review.

Curious if others have tried something similar, or if you rely mostly on compiler warnings (-Wconversion, -Wcast-*) and static analysis for this. Does this feel useful, or just adding noise on top of C’s existing model?

Stack vs malloc: real-world benchmark shows 2–6x difference

Yair Lenga — Wed, 01 Apr 2026 12:02:40 +0000

Usually, we assume that malloc is fast—and in most cases it is.
However, sometimes "reasonable" code can lead to very unreasonable performance.

In a previous post, I looked at using stack-based allocation (VLA / fixed-size) for temporary data, and another on estimating available stack space to use it safely.

This time I wanted to measure the actual impact in a realistic workload.

Full Article (Medium - no paywall):

Stack vs malloc: real-world benchmark shows 2–6x difference

I built a benchmark based on a loan portfolio PV calculation, where each loan creates several temporary arrays (thousands of elements each). This is fairly typical code-clean, modular, nothing unusual.

I compared:

stack allocation (VLA)
heap per-loan (malloc/free)
heap reuse
static (baseline)

Results:

stack allocation stays very close to optimal
heap per-loan can be ~2.5x slower (glibc) and up to ~6x slower (musl)
even optimized allocators show pattern-dependent behavior

The main takeaway for me: allocation cost is usually hidden—but once it's in the hot path, it really matters.

Curious how others approach temporary workspace in performance-sensitive code.

Avoiding malloc for Small Strings in C With Variable Length Arrays (VLAs)

Yair Lenga — Thu, 19 Mar 2026 13:31:00 +0000

Many C programs allocate small temporary buffers using malloc(), even when the buffer only lives for the duration of a function call.

In many cases, stack allocation using VLAs can be significantly faster because it avoids allocator overhead and improves cache locality.

I wrote a deeper analysis including benchmarks and practical guidelines.

Full article (Medium — no paywall):
Using VLA for Faster Temporary Strings in C

The article proposes conditional logic: use a VLA when the requested size safely fits on the stack, and fall back to malloc() otherwise. Small macros hide the decision so the code remains compact and readable.

static void test1(bool show, const char *s1, const char *s2)
{
  // Create char *result - pointing to heap/stack
  FLEX_STR_INIT(result, strlen(s1) + strlen(s2) + 1);

  // Use the buffer
  concat(FLEX_STR_BUF(result), s1, s2)) ;
  printf("result(%zu)=%s\n", FLEX_STR_SIZE(result), result);

  // Release buffer (NOOP is VLA was used)
  FLEX_STR_FREE(result);
}

For small strings this approach can reduce allocation overhead dramatically.

Estimating Remaining Stack Space in a C Program

Yair Lenga — Tue, 17 Mar 2026 23:40:13 +0000

Many programmers believe there is no reliable way to know how much stack space remains in a running C program. Because of this uncertainty, stack allocation techniques such as VLAs or alloca() are often considered unsafe unless the buffer size is extremely small.

On modern Unix systems (Linux, BSD, macOS), the runtime environment actually exposes enough information to estimate the remaining stack space with reasonable accuracy. By combining stack limits with the current stack pointer, it is possible to determine how much space remains before reaching the guard page.

I wrote a detailed explanation, including example code and a small utility function that estimates available stack space.

Full article (Medium, NO paywall):
How Much Stack Space Do You Have? Estimating Remaining Stack in C on Linux

The article discuss 3 techniques:

getrlimit()
pthread_getattr_np()
GCC/CLANG constructor attribute.

Together these allow building a small helper API such as:

size_t stack_remaining(void)
{
    StackAddr sp = stack_marker_addr() ;
    if ( sp < stack_low_mark ) stack_low_mark = sp ;
    return sp - stack_base - safety_margin;    
}

This allows programs to inspect available stack space at runtime and make better decisions when choosing between stack allocation and heap allocation.

Have you ever needed to estimate stack usage in production code?

Forem: Yair Lenga

Optimizing Chained strcmp Calls for Speed and Clarity

From memcmp and bloom filters to 4CC encoding for small fixed-length string comparisons

Full Article: Medium (No Paywall):

Optimizing Chained strcmpCalls for Speed and Clarity

Safer Casting in C — With Zero Runtime Cost

Full Article (Medium - no paywall):

Stack vs malloc: real-world benchmark shows 2–6x difference

Full Article (Medium - no paywall):

Avoiding malloc for Small Strings in C With Variable Length Arrays (VLAs)

Estimating Remaining Stack Space in a C Program

Optimizing Chained `strcmp`Calls for Speed and Clarity