inlining core functionality

[grrrr]

I have made the discovery that in HvMessage.h there are functions declared as static inline which means we are in C99 land anyway.

On the other hand, it is worthwhile to think of inlining all of the lighter functions in the ir2c/static folder.
I have made a small test and it turned out (to my surprise) that the code for a larger patch became actually smaller, and a tad faster.

Many of the generated functions look like this

void Heavy_crossover::cBinop_qMGYbdCE_sendMessage(HeavyContextInterface *_c, int letIn, const HvMessage *m) {
  cBinop_k_onMessage(_c, NULL, HV_BINOP_DIVIDE, 20.0f, 0, m, &cBinop_ppvFApAF_sendMessage);
}

void Heavy_crossover::cCast_jvNer2OG_sendMessage(HeavyContextInterface *_c, int letIn, const HvMessage *m) {
  cBinop_k_onMessage(_c, NULL, HV_BINOP_GREATER_THAN, 0.0f, 0, m, &cBinop_I4bHe9qQ_sendMessage);
}

which (because of the constants) is clearly heavily optimizable in an inline function.
I think that we can rely on the compilers to optimize for speed or size.

[dromer]

Interesting finding!

This kind of changes and optimizations to the compiler architecture feels like something we should do post v1.0 though.
It seems like quite a radical change from how the current setup is done. Of course it's nice to already know there are such optimizations possible!

[grrrr]

I don't think it is such a radical change in principle.
I am not familiar though with all the code targets, though, e.g. how WASM code is optimized.
I can open a branch (since i have it locally already) to test this more closely.
What i don't understand is the function of the HV_EXPORT attributes on some functions. Those are also targets for inlining, but of course accessibility from the outside would forbid this.

[dromer]

For now I definitely don't want to change too many things at once. Climb one mountain at a time :)

It is fine to play around on a feature branch of course. Just make sure to synchronize with the target upstream branch regularly.

From what I can tell the HV_EXPORT is specifically to do with the C++ bindings.

[grrrr]

Ok, let's think about this in the future. I realized that this rebasing is cumbersome.

[dromer]

What I usually do:

• switch to target branch (ie. git checkout feature/expr-sig)
• git pull
• switch to feature branch (ie. git checkout feature/expr-sig-factorial)
• merge target (ie. git merge feature/expr-sig)

If all branches are up to date this gives the cleanest path.

I see you rebasing on develop, which is not your target. That might be messing up the history.

However I still haven't figured out the CI Actions issue ..

[grrrr]

I see you rebasing on develop, which is not your target. That might be messing up the history.

Yes, that happens when i update the branches on the fork. It keeps rebasing to the main branch.
I'll give up the fork.

[dromer]

I asked agy to analyze this and summarize. Would be nice if someone with an expert eye could review this of course:

LLM output below - formatted for markdown

After inspecting the static C library in static, here are key functions and patterns that could be inlined (or force-inlined) to optimize for speed and/or binary size:

1. Signal Processing (DSP Hot Path) — Speed Focus

• __hv_biquad_f (HvSignalBiquad.h, HvSignalBiquad.c)
  • Current State: __hv_biquad_f is defined out-of-line in HvSignalBiquad.c, whereas __hv_biquad_k_f (the constant-coefficient variant) is static inline in the header.
  • Optimization: Move __hv_biquad_f to HvSignalBiquad.h as static inline.
  • Impact: Eliminates function call frame overhead inside audio vector processing loops per biquad instance. Enables vectorizer register reuse and SIMD instruction scheduling across the DSP block.
• Enforce HV_FORCE_INLINE on Hot DSP Primitives (HvUtils.h)
  • Current State: Primitive functions like __hv_phasor_f, __hv_line_f, __hv_tabread_f, __hv_del1_f use standard static inline.
  • Optimization: Upgrade to HV_FORCE_INLINE (inline __attribute__((always_inline))).
  • Impact: Guarantees inlining across all compilers and optimization levels (-O2, -O3, -Os), preventing compiler heuristics from keeping DSP primitives as function calls when code size limits are tight.

2. Control Message Allocations & Utilities — Speed & Size Wins

• Stack Message Constructors: msg_init, msg_initWithFloat, msg_initWithBang, msg_initWithHash (HvMessage.h, HvMessage.c)
  • Current State: Out-of-line functions in HvMessage.c. Each function body is only 3–5 lines (setting timestamp, numElements, numBytes, and element data).
  • Optimization: Move definitions into HvMessage.h as static inline.
  • Impact: These are called extensively across control message generation. Inlining reduces binary size (3–4 direct instructions vs. call setup overhead) and speeds up control message propagation.
• msg_free and msg_getHash (HvMessage.h, HvMessage.c)
  • Current State: msg_free is a 1-line wrapper around hv_free(m). msg_getHash is a small 5-line type switch.
  • Optimization: Move both to HvMessage.h as static inline.
  • Impact: Eliminates wrapper call indirection.

3. Lock-Free Audio Queue Accessors — Speed Focus

• hLp_hasData, hLp_getReadBuffer, hLp_consume (HvLightPipe.h, HvLightPipe.c)
  • Current State: Small out-of-line functions (1 to 3 instructions) that inspect or advance the ring buffer readHead.
  • Optimization: Move to HvLightPipe.h as static inline.
  • Impact: Reduces latency and function call overhead when checking/consuming parameter updates in the real-time audio thread.

4. Struct Initializers (*_init) — Size & Speed Wins

• Trivial *_init Functions (sDel1_init, sLine_init, sPhasor_init, sBiquad_init, sSample_init, cBinop_init, cIf_init, cVar_init_*, cSlice_init, sTabhead_init, sTabread_init, etc.)
  • Current State: Most *_init routines merely zero-initialize a small struct or assign 1–2 fields (e.g. o->k = k; return 0;).
  • Optimization: Define them as static inline in their respective header files.
  • Impact: Reduces total binary size by removing unnecessary function prologues/epilogues and argument setup at every patch initialization site.

5. Control Object Message Handlers — Speed Focus

• cIf_onMessage (HvControlIf.c) & cVar_onMessage (HvControlVar.c)
  • Current State: Short handlers (~10 lines) performing simple conditional branch/assignment and sending output messages.
  • Optimization: Move to HvControlIf.h and HvControlVar.h as static inline.
  • Impact: Speeds up control signal cascades.

Summary of Trade-offs

Target Category	Recommended Action	Speed Impact	Size Impact
__hv_biquad_f	Inline into HvSignalBiquad.h	⚡ High	🤏 Minimal increase
msg_init* & msg_free	Inline into HvMessage.h	⚡ High	📉 Decreases size
hLp_* read accessors	Inline into HvLightPipe.h	⚡ Medium	📉 Neutral / Decreases
Trivial *_init routines	Inline in respective .h	⚡ Low	📉 Decreases size
HV_FORCE_INLINE on DSP	Add always_inline in HvUtils.h	⚡ High	🤏 Controlled