←back to thread

1371 points yett | 3 comments | | HN request time: 0.001s | source
Show context
rossant ◴[] No.43776470[source]
Am I the only one to be annoyed by this...?

while (this->m_fBladeAngle > 6.2831855) { this->m_fBladeAngle = this->m_fBladeAngle - 6.2831855; }

Like, "let's just write a while loop that could turn into an infinite loop coz I'm too lazy to do a division"

replies(4): >>43776533 #>>43776660 #>>43776679 #>>43776703 #
nemothekid ◴[] No.43776660[source]
I want to assume that the GTA developers did this hack because it was faster than floating point division on the Playstation 2 or something.

But knowing they were able to they were able to blow up loading GTA5 by 5 minutes by just parsing json with sscanf, I don't have much hope.

replies(2): >>43778040 #>>43780821 #
1. badsectoracula ◴[] No.43778040[source]
IIRC the whole parsing performance issue was because the original code was written for the SP campaign of GTA5 that only had a handful of objects to parse data for. That was barely a blip in terms of performance impact and AFAIK was written years before GTAOnline was made (where it became an issue - and even then only became an issue much after GTAOnline was first made).

Writing some simple code that works with the data you expect to have without bothering with optimizations is fine, if anything it is one of the actual cases of "premature optimization": even with profiling no real time is spent on that code, your data wont make it spend any time and you should avoid wild guesses since chances are you'll be wrong (even if in this case it could be a correct guess, it'd be like a broken clock guessing the time is always 13:37).

The actual issue with that code was that, after they reused it for GTAOnline and started becoming a performance issue after some time as they added more objects, nobody thought to try and see what is wrong.

replies(1): >>43781311 #
2. vultour ◴[] No.43781311[source]
Are you actually arguing that using a JSON parser for JSON-formatted data is a premature optimization? The solution here was to use a different format, not a somewhat-JSON-compatible hacked together parser.
replies(1): >>43856376 #
3. badsectoracula ◴[] No.43856376[source]
No, i'm arguing that it wasn't a performance issue for the original purpose of the code and it only became one at much later, in a different project and only after some time long after that code was pushed way beyond what it was originally meant to do.

The premature optimization would be trying to optimize that piece of code without that being necessary given what the code was meant to do.