-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: concat3 #7200
feat: concat3 #7200
Conversation
🚀 Deployed on https://6797fa706daef387b3426d93--noir-docs.netlify.app |
FYI @noir-lang/developerrelations on Noir doc changes. |
Right, my initial reaction would be that concat3 seems like it'd be something that may be better fit for a library. |
Fair enough. I'll close this one, and leave the |
To be honest I don't see any reason why the naive method of two calls to the concat function should be less efficient than concat3. Currently in ACIR, we optimise out the intermediate array. This may not be the case currently but as long as the compiler realizes that the intermediate array is not used other to create the next, then it should be the same. |
@TomAFrench I'd expect it to be roughly the same at least in acir but I would expect concat3 to be faster in brillig |
Description
This builds off #7199 (hence the diff also including the
concat
method. I haven't learned graphite.I might've gone a bit far with this one: an ugly method called
concat3
which concatenates 3 arrays. The question then becomes: where do you stop? Where does the madness end? 4? 5? Maybe extra ones should be created through some metaprogramming magic?Anyway, I would put concat3 to good use immediately, but I could also just use
concat
. If you think that instead I should just useconcat
and accept the slowdown due to the unnecessaryfor
loops when doingarr1.concat(arr2.concat(arr3))
, I guess I could...Problem*
Resolves
Summary*
Additional Context
Documentation*
Check one:
PR Checklist*
cargo fmt
on default settings.