# Std.mem.eql regression **URL:** \ **Category:** Help\ **Tags:** language\ **Created:** [October 11, 2026, 7:12am UTC](https://ziggit.dev/t/std-mem-eql-regression/17916 "2026-10-11T07:12:41Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![pts](https://ziggit.dev/letter_avatar_proxy/v4/letter/p/f17d59/32.png) [@pts](https://ziggit.dev/u/pts)\ **Post date:** [October 11, 2026, 7:12am UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/1 "2026-10-11T07:12:41Z")
Is this a valid regression? I just forwarded the post. > ---
**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\ **Post date:** [October 11, 2026, 7:25am UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/2 "2026-10-11T07:25:23Z")
I don’t know if it’s a regression; but if it is, it should be explored why, instead of jumping to `inline` as a solution as that should be used sparingly due to its semantics. * * * I don’t think they would refuse a PR based on where the author works; it’s just not relevant. ---
**Author:** ![IntegratedQuantum](https://ziggit.dev/user_avatar/ziggit.dev/integratedquantum/32/782_2.png) [@IntegratedQuantum](https://ziggit.dev/u/IntegratedQuantum)\ **Post date:** [October 11, 2026, 9:33am UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/3 "2026-10-11T09:33:16Z")
I think any performance optimization also should come with a reproducible benchmark. Also just inlining things has other costs, and may even have worse runtime performance in certain cases. In this case I would want to see a simple example that clearly shows that it isn’t inlined in obvious cases. At which point it would probably be forwarded to llvm since it would likely affect more functions than just std.mem.eql. ---
**Author:** ![vincentd](https://ziggit.dev/user_avatar/ziggit.dev/vincentd/32/9870_2.png) [@vincentd](https://ziggit.dev/u/vincentd)\ **Post date:** [October 11, 2026, 10:31am UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/4 "2026-10-11T10:31:53Z")
> …because it is **pub fn** without inline llvm doesn’t inline it as often as I want… Correct me if I’m wrong, but whether a function is `pub` or not should have no impact on LLVM optimisations? Unlike C or C++, Zig doesn’t treat each file as a separate ‘compilation unit’, so there’s no need for `pub` functions to have global linkage. The effect he’s thinking of is `export`, I think. * * * > [@vulpesx](#): > > I don’t think they would refuse a PR based on where the author works; it’s just not relevant. People out there have some strange ideas about what Zig’s “No LLM policy” actually means, usually without having read it themselves. I say that because Dmitriy himself appears to recognise the value in keeping your writing AI-free: [GitHub - dmtrKovalenko/zlob: \*Very\* fast recursive file walking and globbing library for Zig, C, and Rust. With gitignore support. 100% POSIX compatible · GitHub](https://github.com/dmtrKovalenko/zlob#license) > P.S. No AI was used in the making of this README.md file thank you for reading it till the end. ---
**Author:** ![AndrewKraevskii](https://ziggit.dev/user_avatar/ziggit.dev/andrewkraevskii/32/2564_2.png) [@AndrewKraevskii](https://ziggit.dev/u/AndrewKraevskii)\ **Post date:** [October 11, 2026, 10:40am UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/5 "2026-10-11T10:40:37Z")
> [@vincentd](#): > > Correct me if I’m wrong, but whether a function is `pub` or not should have no impact on LLVM optimisations? Unlike C or C++, Zig doesn’t treat each file as a separate ‘compilation unit’, so there’s no need for `pub` functions to have global linkage. The effect he’s thinking of is `export`, I think. A believe this is correct. There is actually a way to force llvm to inline function even if it’s not inline. @call has .always\_inline option so he should just use that to test out if function been inlined really gives perf boost for his use case ---
**Author:** ![gwenzek](https://ziggit.dev/user_avatar/ziggit.dev/gwenzek/32/8137_2.png) [@gwenzek](https://ziggit.dev/u/gwenzek)\ **Post date:** [October 11, 2026, 12:15pm UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/6 "2026-10-11T12:15:32Z")
IMO this shows serious limitation about how inlining works in LLVM. let’s look at the code: [https://codeberg.org/ziglang/zig/src/commit/9276a56e3cee12a067f93d719a5e7f2762dd4603/lib/std/mem.zig#L799](https://codeberg.org/ziglang/zig/src/commit/9276a56e3cee12a067f93d719a5e7f2762dd4603/lib/std/mem.zig#L799) it’s two simple guards and one for loops. The guards should always be inlined but the for loop is probably better not inlined unless one of the two is small comptime know string. There is a pass in LLVM that tries to break functions in smaller pieces and allow partial inlining but it’s not enabled by default, and Zig doesn’t enble it either. When the inlining decision is taken, I don’t think LLVM looks at the arguments and leverage comptime info. It’s only once inlined that it can do so. The first problem (splitting function) can be solved in usercode by manually splitting. Std already does this in some places. I don’t know solutions for the second problem ---
**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\ **Post date:** [October 11, 2026, 12:56pm UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/7 "2026-10-11T12:56:08Z")
> [@gwenzek](#): > > I don’t think LLVM looks at the arguments and leverage comptime info. just clarifying for others that zigs concept of comptime, and the optimisers’ (LLVM) are separate; “constant propagation/folding” is the term usually used in optimiser land. ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [October 11, 2026, 3:38pm UTC](https://ziggit.dev/t/std-mem-eql-regression/17916/8 "2026-10-11T15:38:03Z")
> [@vulpesx](#): > > I don’t think they would refuse a PR based on where the author works; it’s just not relevant. This is true however, as an observation, reports from people who have integrated AI into their workflows often contain hallucinations nonetheless. For instance, how are they measuring perf? If they are just repeating what a chat bot told them, that is not welcome on the bug tracker. There’s no “regression” in `std.mem.eql` here. Changes in LLVM optimizations have tradeoffs that affect entire codebases in different ways. Adding `inline` to that function is not a solution, because [Inline Is Not A Hint](https://ziglang.org/documentation/0.17.0/#Inline-Is-Not-A-Hint). I don’t think a hint would be appropriate here either. I got spooked by the title, but it turned out to be nothing 🙁