Commit 17f3640b authored by Jonathan Wilkes's avatar Jonathan Wilkes
Browse files

Add idea about profiling and possible optimization

parent fe5c6610
......@@ -104,3 +104,49 @@ take.
Either way, this feature vastly improves the usability of Purr Data for new
users, giving them a way to quickly generate sounds and experiment with the
interface.
Profile and Optimize Purr Data for Realtime Safety
--------------------------------------------------
Goal: Find the "pain points" in Purr Data's core message dispatcher and
audio engine, and optimize the code where possible to improve the realtime
scheduling of DSP.
Details: The core DSP algorithms of Purr Data tend to avoid system calls,
unnecessary branching, and other calls which would make the performance of
the audio process unreliable. However, there are many areas of Purr Data
which are not optimized for realtime scheduling.
The first order of business would be to profile Purr Data in several areas
to see where problems may be. Some likely culprits are the following:
* parse time for incoming messages from GUI to the audio/messaging engine
* overhead of sending messages to the GUI, especially for visual arrays and
drawing instructions for data structures
* overhead of sending streams of "motion" messages from GUI to Pd to track
mouse position
* overhead of walking the linked list of objects in order to find the object
under the mouse/mouseclick
* overhead of tracking mouse position over a visual array
* overhead of calculating bboxes in the audio process as opposed to GUI
* overhead of calculating text positioning in audio process as opposed to GUI
* overhead of counting UTF-8 code points in audio process to calculate
line breaks
* overhead of handling incoming/outgoing socket traffic in the same thread
as the audio scheduler
* probably other areas
Once we get a sense of the pain points, we can tackle the problem of how
to optimize in a maintainable manner. Some references for this:
* [Guilio Moro's work](https://github.com/giuliomoro/purrdata/commit/9dc3223ece79be5f60a6a629450b52a79b9e050c) on using a separate thread for the socket connections from GUI to the core audio engine (plus all the other socket connections
like netsend, netreceive, etc.)
* Guilio Moro's work on a threaded microsleep for the event loop.
* [Guilio Moro's work](https://github.com/giuliomoro/purrdata/commits/simpler-motion) to simplify GUI communication by handling more of the mouse motion/click
logic in the GUI. This results in fewer messages from GUI to audio engine,
but still requires a linked-list walk in the audio engine to find the
relevant object.
* Matt Barber's link to a new cosine wave generator algorithm that may be
more performant than the current implementation. (Not so important for
current performance, but this may become more relevant once we switch to
double-precision for block samples.)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment