Comment by capableweb
5 years ago
That's very true, and the PoC works for that person. It's not that easy in real-life development though, you can't just switch out the JSON parser and call it a day. Lots of testing has to be done and you have to go through all the previous changes to make sure you're not missing what the previous maintainers did to fix some one-in-a-million issues.
I'm not saying it's impossible for this to be as easy as the author claims it to be. I'm just saying that it might not actually be that easy in reality, if you're on the inside.
Let's say that JSON parser is used in so many other places and we are afraid of regression. Guess what? We can make a new one. Let's call it newImprovedJsonParser(). Use that only at this spot, and you have fixed the issue without breaking other parts. You can then replace the other's once you vet that they are compatible.
You seem to be hinting to Chesterton's fence [0].
[0]: https://fs.blog/2020/03/chestertons-fence/
Accept in this case I don't really see why you'd want a naive o(n^2) parser when it isn't needed. Well besides for slow loading times.
Thanks for sharing this, didn't have a name for this scenario.
OK, don't switch out the JSON parser. Just patch in the caching strlen before parsing the json, and set it back to normal strlen after; and fiddle with the hashmap stuff.
But you do understand the ROI of this relatively simple fix?
At such big amount of scale of revenues, I'm sure that GTA Online has feature flags that can act as canary deploys or A/B tests groups.
Deploy one hacked version (with the dirty fix / hack for this case) to one group, deploy the standard version to another group, measure the ROI and the crash-rate.
If the results are similar, then you validate permanently the fix and live happily after.
6 minutes to 1 minutes 10 is massive, it will even bring new players to join the game (I don't like to play GTA Online, though it's a great game, just because of loading times).