The problem wasn't strlen(), that just showed up at the bottom of the call stack when profiling.
IIRC the actual problem was an exceptionally dumb JSON parser combined with parsing a pretty big JSON file (which probably also grew much bigger than the original developer working on that feature anticipated).
Edit: the title has been edited in the meantime, originally it was something about strlen() being responsible for the slow loading time.
It wants to reuse code in fscanf(), but for that it needs a FILE * interface. But to create that, it needs to implement EOF-handling, and to do that it needs to provide a size, so it has to call strlen().
I had no idea. :|
The speedup gains were not caused by reducing the size of the JSON file or doing any exceptionally better JSON parsing. The speedups were a direct result of simply not calling strlen() over and over in an O(N^2) fashion.
I bet the "official" patch by Rockstar simply dropped in a less embarassing JSON parser library :)
{"foo": "bar"}
{
"foo"
:
"bar"
}
The JSON to be parsed was read in from somewhere, either a file or received over the network. When that happened the machine knew how long it was.
One of the few places where C++ is sometimes better about things than Rust is providing information gathered which is ancillary to the direct purpose, in case you wanted it, so that you needn't then ask for the same information a moment later. In Rust this information may have a difficult to ascertain lifespan, and so it's dangerous, but in C++ they figure the out-of-date nature of the report is your problem. Sometimes to your detriment of course, but often you could really have used that and must now go measure it yourself because the thing you just called knew it but didn't tell you.
Here though it wouldn't matter, Rust's array types, and both the owned mutable String and reference &str types know how long they are, so you are never flailing about counting even once. You also would just serde_json this data in Rust because serde is practically part of the Rust Standard Library, whereas there's nothing quite so ubiquitous in C or C++.
A: a processing state (int/enum). B: a current fmt str pointer. C: va_list struct to keep track of destinations. D: a source string pointer.
Now if what I saw mentioned in another comment is true that there is some insane conversion to a FILE* stream to do this, then yes I can see why it happens but it's not really NEEDED to implement the function as specified.
I hope it's gone. I really do hope it's gone :-)