user142: I was about to spend some time researching this, but realized someone might have already looked into it; if not, I may just answer my own question in a few hours.
Scid is pegging one core of the CPU, possibly trying to keep up with input from Stockfish? Stockfish is using 0% CPU, possibly blocking while piping output to Scid. That is just what I suspect is happening--haven't confirmed. In any case, stockfish takes a minute or two to get to 2 depth in analysis--usually after a few seconds I'm to 15 depth at least, so it's orders of magnitude slower.
I didn't change any of my UCI settings, just simply upgraded the executable. Same thing happens on Mac and Windows, so it's probably not platform specific, but something related to the UCI interface?
I have hash size set to 1024MB, "use sleeping threads" = true, and multiple variations set quite high (100 or so), to see all variations scored and searched, which helps in analysis even though it slows down the depth search. The rest of the settings are default (I'm fairly certain).

user142: So, I hashed this out some in a support thread on the stockfish forum.
Basically, you should skip 2.2.2 and compile the latest from github (or just continue to use 2.1.1). I think I'll try this new code for a while to see how it does. The latest code from github works great in chesstempo's UCI connector. It's still a little slow out of the gates in Scid (and Scid acts like it's hanging and doesn't respond to UI commands), but it speeds up as it gets deeper in the search, so it's bearable after 30 seconds or so. I had trouble getting multipv (multiple variations) to work at high numbers, though.
I think Scid should not block the input from the UCI interface--buffering more, if need be. Maybe I'll take a look at the Scid code later to see if I can improve it.

142: <p>I was about to spend some time researching this, but realized someone might have already looked into it; if not, I may just answer my own question in a few hours.</p>

<p>Scid is pegging one core of the CPU, possibly trying to keep up with input from Stockfish? Stockfish is using 0% CPU, possibly blocking while piping output to Scid. That is just what I suspect is happening--haven't confirmed. In any case, stockfish takes a minute or two to get to 2 depth in analysis--usually after a few seconds I'm to 15 depth at least, so it's orders of magnitude slower.</p>

<p>I didn't change any of my UCI settings, just simply upgraded the executable. Same thing happens on Mac and Windows, so it's probably not platform specific, but something related to the UCI interface?</p>

<p>I have hash size set to 1024MB, "use sleeping threads" = true, and multiple variations set quite high (100 or so), to see all variations scored and searched, which helps in analysis even though it slows down the depth search. The rest of the settings are default (I'm fairly certain).</p>
 142: <p>So, I hashed this out some in a <a href="http://support.stockfishchess.com/discussions/problems/163-performance-with-stockfish-222-vs-211" rel="nofollow">support thread on the stockfish forum</a>.</p>

<p>Basically, you should skip 2.2.2 and compile <a href="https://github.com/mcostalba/Stockfish" rel="nofollow">the latest from github</a> (or just continue to use 2.1.1). I think I'll try this new code for a while to see how it does. The latest code from github works great in chesstempo's UCI connector. It's still a little slow out of the gates in Scid (and Scid acts like it's hanging and doesn't respond to UI commands), but it speeds up as it gets deeper in the search, so it's bearable after 30 seconds or so. I had trouble getting multipv (multiple variations) to work at high numbers, though.</p>

<p>I think Scid should not block the input from the UCI interface--buffering more, if need be. Maybe I'll take a look at the Scid code later to see if I can improve it.</p>
