The OBJ parser was primarily using StringRef for convenience, with functions like "skip whitespace" or "parse a number" taking an input stringref, representing an input line, and returning a new stringref, representing the remainder of the line. This is convenient, but does more work than strictly needed -- while parsing, only the "beginning" of the line ever changes by moving forward; the end of the line always stays the same. We can change the code to take a pair of pointers (begin of line, end of line) as input, and make the functions return the new begin of line pointer. This makes the return value neatly fit into a processor register, which StringRef did not.

On Windows, this does result in non-trivial speedups in the actual OBJ file parsing part, due to Windows calling convention where return values larger than 64 bits are returned via memory. Does not measurably affect performance on Mac (and I guess Linux?), because the calling convention there uses a pair of 64-bit registers to return a StringRef.

End-to-end times of importing several test files, on Windows (VS2022 build, Ryzen 5950X):

• Monkey subdivided to level 6, no normals (220MB file): 1.25s -> 0.85s
• Rungholt minecraft level (270MB file): 7.0s -> 5.8s
• Blender 3 splash scene (2.4GB file): 49.1s -> 45.5s

The full import process has a lot of other overhead besides actual OBJ file parsing (mostly creating actual blender objects out of parsed data). In pure parsing, in the monkey test scene above, the parsing part goes 1.0s -> 0.6s.