On Dec 25, 2017, at 10:23 , Daryle Walker <dary...@mac.com> wrote: > > What happens if whichever byte value is second is gigabytes away from the > first?
Your Data extension code doesn’t solve that problem anyway: > var firstCr, firstLf: Index? > enumerateBytes { buffer, start, stop in > if let localLf = buffer.index(of: ParsingQueue.Constants.lf) { > firstLf = start.advanced(by: buffer.startIndex.distance(to: > localLf)) > stop = true > } > > if let firstCrIndex = firstCr, firstCrIndex.distance(to: > start.advanced(by: buffer.count)) > 2 { > // No block after this current one could find a LF close > enough to form CR-LF or CR-CR-LF. > stop = true > } else if let localCr = buffer.index(of: > ParsingQueue.Constants.cr) { > firstCr = start.advanced(by: buffer.startIndex.distance(to: > localCr)) > stop = true > } > } In the case where the Data object is *one* multi-GB buffer, if it doesn’t contain a LF you will search gigabytes for the non-existent LF before searching them again for the CR. Even if you’re lucky and the Data object is multiple smallish-buffers, you will still search all the buffers that don’t have a CR for a LF, before you find the one that does have a CR. So, if your goal is to minimize searching, you have to search for CR and LF simultaneously. There are two easy ways to do this: 1. Use “index(where:)” and test for both values in the closure. 2. Use a manual loop that indexes into a buffer pointer (C-style). #1 is the obvious choice unless invoking the closure is too slow when a lot of bytes need to be examined. #2 would use “enumerateBytes” to get a series of buffer pointers efficiently, but there is no boundary code to be tested, since you’re only examining 1 byte at a time. Once you have the optional indices to the first CR or LF, and you find you need to check for a potential CR-LF or CR-CR-LF, you can do that by subscripting into the original Data object directly, outside of the search loop. This approach would eliminate the problematic test case, and (unless I’m missing something obvious) have the initial search as its only O(n) computation, everything else being O(1), i.e. constant and trivial. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com