I've recently moved Sonar Platinum to a new computer with a Core i7-6700 4 GHz CPU.
I'm also seeing momentary UI freezes during recording where the Now point freezes, the cursor spins, and the title bar changes to "not responding".  After a few seconds it seems to recover, but the recorded audio trace lags behind the Now cursor for the rest of the take.  I never saw that before with the old system which was a 10 year old Core-2 Duo.
 
One thing I notice is when I'm performing time-consuming tasks such as importing and exporting audio, the CPU utilization in Resource Meter never exceeds 12%.  These tasks still take many minutes for long audio clips. Are there some settings I need to adjust to enable Sonar to take advantage of a modern multi-core CPU?
 
 

Preferences->Audio->Playback and Recording.  Check box "Use Multiprocessing Engine". If you are up to date with September's update (IIRC) there is also a new feature Plug-in Load Balancing.

TIMG11,
 
There are known issues with the CPU you are using if it is using the built in GPU.  I had am early computer from HP with this feature and CPU and had to send it back to HP 2 times before they updated it with a new CPU with the FIRMWARE fix for the bug.
 
Since they(HP) replaced the CPU, absolutely no more glitching with that computer.  As a backup, I added a graphics card to that machine to avoid using the built in graphics processor.  Don't know if this is part of your problem but just wanted to give you a heads up.

I already had Use Multiprocessing Engine checked. I added Plug In Load Balancing.
 
I think the recording and playback are working OK, but I'm seeing low performance on audio import and export. Are they multi-thread optimized?

I'm still not seeing proper use of multi-core, or even one core, for compute-limited tasks. (@jimkleban, I am not using the built in graphics in the Intel chipset- I have a separate NVIDIA video card)
 
Example Scenario:  File / Import Audio.  Import a 1 hour long MP3 file (44 khz stereo).
On a 4 GHz i7-6700, this takes about 20 seconds.
Resource Monitor shows processor utilization of about 3%.  Detailed CPU view shows one core at about 50%, others unused.
 
Example Scenario: Normalize Track.  Takes about 10 seconds
Resource Monitor shows processor utilization of about 2.5%.  Detailed CPU view shows one core at about 50%, others unused.
 
What am I missing? Why is the CPU underutilized? I know multi-processing is not perfect, and I won't see 8 cores at 100%, but I expect better than 5% total CPU utilization while I'm sitting waiting for a single-threaded (UI blocking) task.
 
 

One positive finding - I found when I export three tracks simultaneously (separately, not mixed down), Sonar will use three CPUs, each at about 4%, for a total of 12%.  So it is multi-threading, but still not taking advantage of the processing power available.
Export Audio is a single-threaded task - you get a spinning cursor and can't do anything else with Sonar while it is running. If 88% of the CPU power is available, and no other applications are using it, why doesn't Sonar use more CPU and get the job done faster? It is not limited by the disk.

I still think it is odd that when Sonar is the performing a application-modal operation like Export Audio (spinning cursor - fully occupying the UI so no other action is possible) that it would only use 12% of the available CPU. 
 
Does anyone else see this behavior? 

timg11why doesn't Sonar use more CPU and get the job done faster?

old code that would be cumbersome to update

Importing a one hour mp3 file means converting it to WAV. A one hour long stereo WAV file would be about 600MB. You're also reading the file which is maybe 60MB big. So 660MB in 20 seconds is 33MB/s disk throughput, 30 of which is writing. While that shouldn't max out a modern disk per se it seems to me you're assuming the CPU is throttling the process for no reason, and that's almost never the case, with any software.

By the way the Skylake series has a lot of power saving features, you may want to use a program like Throttlestop to ensure cores aren't being slowed down or idled all the time.

Maybe the particular jobs you are looking at are just not CPU intensive. The 12% behavior could happen if there is nothing much in the way of effects so the whole task is waiting for reading audio from disk or writing a long audio file.
 
In one of your examples, exporting multiple tracks may be bound by disk input and there is not much processing to be done. So it is multithreaded, but not much for each processor to do.
 
Normalizing a track requires disk reading and writing the whole track and very little CPU, so no multithreading would help.
 
Your import MP3 example is a single-threaded task by nature and is probably limited by disk I/O, not needing the CPU much for decoding. Besides waiting for the MP3 to be read from disk, there can also be a limit for writing the decoded data to disk, depending on how much buffering is available. Decoding an MP3 writes much more data than it reads. For a very large MP3, there will definitely be a disk writing limit.
 
In general, it's possible that the kind of jobs you are waiting for would be sped up much more by an SSD rather than more RAM or a faster CPU. If you had a slower CPU, you would see a higher utilization percentage but probably no slowdown for these jobs.
 
The momentary freezes etc. are most likely OS or hardware problems that need study.