[go: up one dir, main page]
Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Slow compilation #1010

Open
sletz opened this issue Apr 11, 2024 · 0 comments
Open

Slow compilation #1010

sletz opened this issue Apr 11, 2024 · 0 comments

Comments

@sletz
Copy link
Member
sletz commented Apr 11, 2024

From Dario Sanfilippo

Speaking of the compiler being slow when using partial application, see this code snippet below:

gainAttenuation(isLogDomain, th, att, hold, rel, x) = scaler ~ _
    with {
        scaler(s) = ba.if(isLogDomain, logDomainScaler, linearScaler) , debugSig
            with {
                //peak = peakHoldCascade(32, att + hold, x) * (1.0 - satAmount) + th * satAmount;
                peak = att + holdScaled , x @ (.025 * SR) : peakHoldCascade(32);
                holdScaled = hold * sss;
                peakUnhold = .025 , x : peakHoldCascade(32);
                linearEnvUnhold = max(th, peakUnhold) : smoothing;
                linearEnv = max(th, peak) : smoothing;
...

peakHoldCascade(32) instantiates 32 peakHolders inside. If I give holdScaled as a param, which also has a long tree inside with 32 instantiations, without using basic syntax, it will be duplicated inside each instance of the peakHolders inside peakHoldCascade of the function peak, so things escalate exponentially in that case.

Using basic syntax like I'm doing here cuts compilation times by a factor of 30 or 40. Really a lot.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sletz