filterx/expr-regexp-common: avoid excessive zero initialization of FilterXReMatchState

[bazsi]

No description provided.

[bshifter]

help me to understand this one please. i dont get why it is better to leave the half of the struct uninitialized.

[bazsi]

help me to understand this one please. i dont get why it is better to leave the half of the struct uninitialized.

The memset() call in the cleanup() function showed up in one of my profiles and doing that after cleaning up is not needed at all.

Once I was there, I looked at regexps in general, and it seems that they always allocate the result structure (pcre_match_data), this is pretty unfortunate, pcre1 did not need this and our malloc() usage is the #1 reason for our scalability issues.

zero filling structs is something I prefer too, especially for structs that are initialized outside of the hot path.

For hot path initializations, I try to decide the risks vs overhead of zero filling the struct, that's why I removed it. Whether we want to optimize regexps depends on how many of them we would apply per message. Right now we have 4-5 in the axo-fallback case which is probably what we have to optimize the most.

The memset removal in the initialization part can be argued, we can add it back, but that's how I ended up removing it, probably not the most important optimization in the series. The struct itself is 48 bytes, similar to FilterXScope (which is 40 and which has the memset call), but I felt it was a relatively simple where fields were all initialized before use, except the two that is cleaned up in the cleanup function.

[bshifter]

Thank you, I think I understand your point now. We’re in agreement regarding the deinitialization part, but for the initialization, I initially leaned towards a 'better safe than sorry' approach. However, you’re right—since every element of the struct is explicitly set later, additional safeguards aren’t necessary.