Yeah that seems strange - lip sync computing can take some time, but I've never seen it take that long.
Is the SSD an external drive? If so, do you see any improvement by switching the location to an internal one?
What audio format are you using and what specs does it have (sample rate, bit depth, etc)?
If you try to compute for a super simple puppet like the default blue guy from the Welcome panel, does it go any faster?
That operation is about 8-12x faster in the internal builds versus Beta 5. The original usage pattern was just for keeping up with audio as it was recorded, but a small adjustment opened it up to go much more quickly in the case of pre-recorded audio. That particular code doesn't actively exploit parallelism, but in recent builds it does at least keep 1 core saturated to go as fast as (serially) possible (which in your case probably means it'd use closer to 16% of available processing for your 6 core system).
I'm still surprised that it was taking so much more than the duration of the clip since lip sync is generally able to keep pace as audio is recorded. Without looking at whether there's something particular to your audio file, I'm not sure how to explain that part. Is there anything unusual about the clip (sampling rate, number of channels, etc)? Do you have other clips that finish in a time closer to the duration of the clip, or do all compute lip sync operations behave like this on your system?
If it was on a Mac and you'd switched another app in front while you were waiting, app nap could slow the signalling of the processing loop and stalling it out, but it sounds like you're on a Windows system and I'm not aware of anything as heavy handed as app nap can be on Windows.