Optimizing in TouchDesigner: Performance Monitor

The difficulty of optimizing

I did an online workshop focused on optimizing projects in TouchDesigner last week because I think it’s a hugely under-discussed topic. Optimization is a tool and thought process that should be introduced more and more to new and intermediate users. The biggest difference between optimization and “regular programming” is the method and approach. In this post, I discuss common themes I try to impart on developers when I’m talking about optimizing, and give an overview on TouchDesigner Performance Monitor and Probe.

Know your toolset

The first and simplest thing to do is learn about your toolset. While some of the other things to know about optimization are more abstract, the tools are concrete and do certain things. In TouchDesigner we have two main optimization tools, the Performance Monitor and Probe. We won’t go into too much detail about them here, I’ll give a quick overview. The best way to learn these is through using them repeatedly and getting more comfortable with them. It only takes a little bit of effort to understand them, but it takes a lot of effort to become comfortable using them.

TouchDesigner Performance Monitor

TouchDesigner’s Performance Monitor is essentially a waterfall chart that shows the CPU computation time of all the operators inside of TouchDesigner. This includes the operators needed to actually create the network editor (like graphics and text in the timeline). If you’ve ever done web development, you’ll be familiar with how it works. If not, the idea is simple:

• Tthe top is the start of the frame and bottom is end of frame
• It lists all the operators in the order they are computed and how long they take to compute in milliseconds
• The bigger the bar, the longer something is taking to cook. You’ll want to find big bars and try to get rid of them.

TouchDesigner Performance Monitor uses

Performance Monitor has a number of different uses, but the main uses are:

1. Get a detailed analysis of the current frame and why it might be running slowly
2. Use the frame trigger to get an analysis of a recurring dropped frame (since it’s extremely difficult to perfectly hit Analyze on the frame that might be the issue)

You’ll find it with shortcut F2 or in the menu at the top of the screen under Dialogs.

TouchDesigner Probe

Performance Monitor is your detailed view of a single frame, TouchDesigner’s Probe is less detailed in regards to each frame, but it allows you to see network performance over a series of frames. You’re essentially seeing time instead of detail. I like to think of the audio equivalent of audio FFT’s, and the difference between time domain and frequency domain data (see gif below from Wikipedia)

Uses for Probe are:

1. Visualizing cook dependencies (if everything in a network is cooking and only a few things are changing, re-arrange the operators!)
2. Getting an intuitive sense of what functionality in your project is causing slow downs so that you can then proceed with deeper analysis

You’ll find Probe in the Palette with shortcut Alt + L or by going to the dialog menu at the top.

Know your hardware

The next step to optimizing is knowing your hardware intimately and how it is being used and how much headroom you have. The biggest secret to optimizing in TouchDesigner is that aside from all the little tricks you can do to make things faster, the real meat of optimizing is a balancing act. Optimizing is really just taking some work off of one part of the system and giving it to another part of the system that is idle. If your CPU is under heavy stress running particle systems, you might want to move extra work off of the CPU and onto the GPU if you can.

Movie codecs are an easy example of how a small change in file format can change between putting more stress on the CPU in exchange for less stress on the storage I/O (aka using H264) or you can move a lot of the work to the GPU and storage I/O and leave the CPU far less stressed (HAP family of codecs). There’s no hard and fast rules about which codec you should use, it really depends. If you’re GPU is under heavy stress and you know that your hardware doesn’t have a ton of storage I/O, then HAP codec may not be a great choice, and you can optimize your project simply by using another codec that will use the CPU instead.

But you need to know your hardware and headroom. If you don’t, then you’ll never be confident in your balancing decisions.

Measure, iterate, measure, iterate

The subtitle of this section would be Take a lot of measurements. Once you’ve started getting comfortable with the tools, know your hardware, and you’re experiencing slow downs, I don’t care what anyone says, there is only one consistent formula for optimizing effectively and efficiently:

1. Measure the current state of the network multiple times
2. Make one small change that you think can benefit the performance
3. Measure the new state of the network multiple times
4. Rinse and repeat till you don’t have performance problems!

That is the magical secret of optimizing in TouchDesigner (and anything really). Nothing more. Many people think it’s a magical act that you need secret knowledge to achieve. It really just comes down to having patience to have accurate measurements, make a small change, and taking new measurements. And you just keep moving in the right direction and avoiding changes that would add time and you’ll eventually reach a fast and stable network. The magic of optimizing in most cases is just that people who practice optimizing a lot can do this cycle of measuring and iterating on small changes extremely quickly.

A game of millimeters not meters

I know I said the that measuring and iterating is the secret to TouchDesigner, but if there was a second secret it would be this: optimization happens fractions of a milliseconds. Unless you’re just starting with TouchDesigner, you will probably be working in a way that is conducive to generally good performing TouchDesigner projects. And all the while you’re working in the correct “style” you still might be getting performance issues and won’t know what to do. “I did it the way they said!” you might yell. After a certain stage of proficiency, you won’t have giant bars in performance monitor or big red/black disks in probe. What you’ll have instead is tons and tons of blue/green discs. This is what I mean by a game of millimeters. In almost all projects I work on, 80% of the optimization I’m able to introduce is from taking 0.05ms off of the cook time of 50 operators (saving 2.5ms) or taking 0.1ms off of 12 operators (saving 1.2ms). These are the gains you’re looking for. You won’t be finding operators dropping from 10ms to 1ms because of some trick (unless you’re new to TouchDesigner and still learning).

This only goes to reinforce the patience required in the last step and really the importance of measuring and iterating. It’s honestly extremely common for me to hook up an Info CHOP to an operator, isolate the cook_time channel, plug it into a Trail CHOP, then change a single thing on and see if I can save 0.01ms. I consider that a big win these days as I’m often scrounging for 0.001ms in TouchDesigner projects!!

Wrap up

You’ve got the tools and the mindsets now to get started with optimizing. The best way to do it is to have some patience and just get started. If you get stuck on how to make something a little bit faster or how to setup a network to reduce cooking dependencies, the TouchDesigner commuity is there to assit! Just remember the key steps to getting started:

1. Know your toolset
2. Know your hardware
3. Measure and iterate a ton
4. Aim for tons of tiny wins

Happy optimizing!