Advanced Gtk+ Sequencer - News

Group

Main
- Main
- View members
- Search
Homepage
Download
Docs
Support
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
Mailing lists
Source code
Bugs
- Submit new
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
Tasks
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
News
- Browse
- Atom feed
- ~~Submit~~
- ~~Manage~~

Constant CPU consumption by bisection

Item posted by Joël Krähemann <jkraehemann> on Tue 05 Feb 2019 05:12:51 PM UTC.

For short, I am just refactoring some parts of:

AgsNotation
AgsAutomation
AgsWave

to do bisection x-offset. This shall result in better performance and more constant CPU consumption.

Prior, I recognized as doing low-latency playback using AgsWave, to encounter bottlenecks. This was solved by refactoring:

ags_wave_find_point()

This function does bisection as of Advanced Gtk+ Sequencer version 2.1.38.

The refactoring

I just implemented:

ags_notation_find_offset()

... returning a GList containing all x-offset matching AgsNote objects. It uses bisection to find matches.

Another refactored function is:

ags_automation_get_value()

So guess, it does bisection, now.

Bisection segments

For now, I work on refactoring:

ags_notation_find_near_timestamp()
ags_automation_find_near_timestamp()
ags_wave_find_near_timestamp()

Doing bisection segments is going to provide enormous performance payback as doing continues playback/recording. Because the algorithm looks at the first, last and center element.

Especially recording benefits of this, since the last segment is lookup very fast.

Since all these functions involve mutexes, the lock count is more constant and is slightly reduced during playback.

by Joël