Should have got guys that grew up with the 8-bit micros to write up a spec.
The problem was, they had to sell their invention to other guys that had grown up with 8-bit micros and in the meantime had gotten very attached to their specific 8-bit encodings, so they had to make a lot of compromises: first 128 characters match ASCII; first 256 characters match Latin-1; alphabets encoded in order; codepoint-to-codepoint transcoding from any (reasonable) legacy encoding; throw out enough stuff to not need more than 2^16 characters. They were also racing against time, because in the meanwhile ISO was cooking up 10646, the Universal Character Set, built around ISO 2022’s teletype-inspired architecture of charset switching, and that only got killed because software vendors essentially declared a boycott and pointed to Unicode instead.
The result came out rather awkward as well as fairly expensive, and a lot of the promises needed to be broken afterwards anyway. But they’d have no users had they had done things differently. (Meanwhile, the UCS as initially conceived lacked such advanced operations as string equality.)
The best case is a simple mask. I don't see how that can be done, given how Unicode can reclassify if something is a whitespace.
The worst case is 25 if-equals tests, so I'll call it 25 cycles since most text is not whitespace.
A 32-bit multiplication, shift, an L1 lookup, and comparison is fast. Eyeballing I'll guess about 8 cycles.
A mask and compare would be, what, 2 cycles?
While the loop to read these code points -- likely with utf-8 decoding -- adds its own overhead, plus the function call overhead, of course.
I am very much not a low-level developer, so take these numbers with caution. They are meant only to give some estimate on what "much" means.