-
Notifications
You must be signed in to change notification settings - Fork 40
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
Perform on-demand score updates only #1380
Comments
Optimization 1: push There is currently a private The strategy here is to defer the check that Test functions:
Starting input, output:
Observation: as note count doubles, attach time quadruples. Then 2 indicators per leaf:
3 indicators per leaf:
4 indicators per leaf:
Observation: runtime increases linearly with indicators-per-leaf. Observation: runtime increases exponentially with leaves-per-voice. Solution: call Performance with this optimization:
|
Profiling shows the areas of biggest performance improvement in Abjad will come from limiting the number of score updates Abjad performs. What is a score update? A score update is a behind-the-scenes traversal of every note in a score that Abjad performs to bring start-offsets, stop-offsets and a few other properties of components up-to-date. (Consider removing the first note from a voice with 1000 notes: the start- and stop-offsets of the remaining 999 notes all change after the first note is removed. Abjad accomplishes this with a score update.) Score updates are fast. But score updates are also the biggest source of exponential increases of runtime in Abjad because several parts of the system loop over (loops of) score updates, each of which necessitates a full-score traversal.
Strategies for reducing the number of score updates Abjad performs must balance the need to keep score information up-to-date (as sketched above) against runtime performance. Until now, Abjad has favored the up-to-date-ness of score information against runtime performance, by attempting to update score information soon after any structural feature of the score changes. (In addition to adding and removing notes, such structural changes include adding and removing time signatures, metronome marks and other contexted indicators that determine the measure number and duration-in-seconds of components.)
Starting with Abjad 3.5 or 3.6, I'll begin the process of changing this balance. What this means is that score updates that Abjad currently performs behind-the-scenes (meaning without users knowing that the updates are happening) will become on-demand, meaning that composers will decide when score updates should happen (and will then call a convenience function to do so). The trade-off of these changes is clear: Abjad's runtime performance will increase for all users, but composers will be responsible for calling score updates before operations that need up-to-date score information.
The work will be batched because Abjad's score updates fall into groups; batches will appear in the comment history of this thread.
The text was updated successfully, but these errors were encountered: