{"id":38572,"date":"2023-02-23T14:33:38","date_gmt":"2023-02-23T19:33:38","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=38572"},"modified":"2023-03-10T15:15:36","modified_gmt":"2023-03-10T20:15:36","slug":"speeding-up-scanner-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/02\/23\/speeding-up-scanner-in-swift\/","title":{"rendered":"Speeding Up Scanner in Swift"},"content":{"rendered":"

My first tip goes back to when I started using NSScanner<\/code> in the Puma days. In short, you should never call scanCharacters(from:into:)<\/code> in a loop because every time it’s called it creates an inverted copy of the character set. It then delegates to NSString.rangeOfCharacter(from:options:range:)<\/code>, passing that copy. The documentation<\/a> contains the cryptic comment:<\/p>\n

\n

Using the inverse of an immutable character set is much more efficient than inverting a mutable character set.<\/p><\/blockquote>\n

But my experience is that it’s not fast with immutable characters sets, either. It seems like there should be an NSCharacterSet<\/code> subclass that flips the membership of another object. Then each character set could store its own inverse with minimal overhead and just return the same one each time. But there’s apparently no such optimization, so I recommend calling inverted<\/code> yourself, storing the result, and then using scanUpToCharacters(from:into:)<\/code>, which will then use the character set unchanged.<\/p>\n

Even this is very slow when calling from Swift, though. Whenever you call scanUpToCharacters(from:into:)<\/code> with a CharacterSet<\/code>, it calls CharacterSet._bridgeToObjectiveC()<\/code>, which calls __CFCharacterSetCreateCopy()<\/code>, which again makes an expensive copy. (I have been doing a lot of profiling but somehow didn’t notice this until Ventura, so I wonder whether something changed there.) In any case, currently CharacterSet<\/code> does not bridge efficiently like Data<\/code> and String<\/code> do.<\/p>\n

My first try at working around this was to do the bridging up front:<\/p>\n

let fast = characterSet as NSCharacterSet<\/pre>\n
and then pass the same NSCharacterSet<\/code>, which should bridge cheaply, each time. But this didn’t help.<\/p>\n
What did work was to create an NSCharacterSet<\/code> directly:<\/p>\n
let fast = NSCharacterSet(bitmapRepresentation: characterSet.bitmapRepresentation)<\/pre>\n
With that change, the bridging overhead goes way. Scanner<\/code> is still not particularly fast, though. Maybe this will improve with the forthcoming Swifty Foundation<\/a>, or I may end up writing a replacement for just the few cases that I need that works directly on Swift strings.<\/p>\n\n
Previously:<\/p>\n