(volume 0) optimization

[elydpg]

This is more of a question for discussion, however I thought I would bring it up in a new issue here. Given that (vol 0) is essentially muted, I am wondering if there is a way to internally optimize for this, as it is the equivalent of using rests / omitting an instrument instance for as long as the volume remains at zero.

As a test, I created two identical alda files, one with 4096 rests and one with 4096 C notes played at volume zero. I am not quite sure how they would differ parser and performance wise, however I am struggling to perform the tests as 1. I do not know the internal metrics to check for 2. You can't actually hear any music and 3. I'm still getting non error errors like these

[27713] Starting Alda server...
[27713] Server up ✓
[27713] Starting worker processes...
[27713] Ready ✓
Elys-Computer-Mac-OS-Edition:~ elygolden$ alda status
[27713] Server up (4/4 workers available)
Elys-Computer-Mac-OS-Edition:~ elygolden$ alda play --file /Users/elygolden/Desktop/vol_test2.alda 
[27713] ERROR Alda server is down. To start the server, run `alda up`.

Anyway thought I could open this up as a discussion issue. There's still a lot of stuff to work out before the official release...

[daveyarwood]

I think the [27713] ERROR Alda server is down. To start the server, run alda up. error you're getting might actually be the result of it taking > 3 seconds for the score to finish parsing + evaluating. Until we have the worker status pipeline in place ( #260 ), when you run alda play, the client will give up and if it takes longer than 3 seconds for the worker to parse and evaluate a score.

One thing you can do is time the individual parsing and evaluating steps. Actually, the best way to do this is by running the benchmarks in alda.examples-test.

1. Install Boot.
2. Clone this repo.
3. Add your example scores to the examples directory, and make sure that they end in .alda.
4. Add the file names (minus the .alda extension) to the list of scores to benchmark here.
5. In the root directory of the repo, run boot test -n alda.examples-test.

For each file in examples, you should see output like this:

Testing alda.examples-test

 across_the_sea.alda
   Parsing as code...        OK (28 ms)
   Evaluating score code...  OK (23 ms)

   Parsing as score...       OK (26 ms)
   Realizing parsed score... OK (5 ms)

This tells you the number of milliseconds it took to do each step. You can ignore the top two lines in this case -- the bottom two lines ("Parsing as score" / "Realized parsed score") are representative of what happens when you run alda play.

[elydpg]

Cool! I'm not really inclined to install more libraries atm (i.e. Am too lazy). I would be definitely interested in which score takes longer though.

[daveyarwood]

I just tried it and both scores triggered a stack overflow during the parsing phase. The reason is that our parser is optimized to expect something that's not just a single letter every now and then. Usually an Alda score won't have this many single-letter "words" in a row, so it won't be a problem in practice.

I was able to avoid the stack overflow by trimming each score down to 896 notes. Here is the result:

rests.alda
   Parsing as code...        OK (273 ms)
   Evaluating score code...  OK (27 ms)

   Parsing as score...       OK (353 ms)
   Realizing parsed score... OK (21 ms)

 silent-notes.alda
   Parsing as code...        OK (450 ms)
   Evaluating score code...  OK (55 ms)

   Parsing as score...       OK (427 ms)
   Realizing parsed score... OK (35 ms)

Not surprisingly, rests are more efficient, but it doesn't seem to make a huge difference.

[daveyarwood]

If we were to optimize this, this line would probably be the place to do it. On this line, we're constructing a vector of notes to be added to the score. We already have a check to see if the duration of the note is 0 -- if so, no note should be added because a note with a duration of 0 is theoretically just silence. We could also add a check that volume is not 0.

I think this is a premature optimization though, and I don't want to inadvertently break something so I'm in no rush to try it. If someone else can try this change and verify it won't break anything (and maybe add unit tests / benchmarks), I'd happily review a PR.

[daveyarwood]

Moved to alda-lang/alda-core#22.