Yes and no. The author was making the point that each new LIT relied on an input-dependent branch, whereas when you're decoding XOR [a,b,c] the branch is on the pre-decoded length of the instruction. LIT could be encoded like this but isn't.
Got it, there's no "LIT w/length" instruction in LZSS, so it's logically a new compare-and-branch every time a literal character is hit. I hadn't regarded it as a performance-wise argument, but size-wise for some reason.
The whole:
could have been written as a single instruction: It's almost as if author tries too hard to support their point that their variant looks better."Notice how much faster it makes progress through the file vs. LZSS"
Yeah, because you encode every literal separately? It's all LIT instructions?