What would have been the purpose of stupid code like that?
Was it a workaround for things that didn’t fully complete on one iteration, so the devs kept hammering away at it until it worked?
What would have been the purpose of stupid code like that?
Was it a workaround for things that didn’t fully complete on one iteration, so the devs kept hammering away at it until it worked?
They were most likely just bugs. Quite possibly really stupid bugs.
Not every bug results in the program doing the wrong thing, they often just make the program do the right thing very slowly.
And nobody notices, since it still produces the right result.
Yes, they were bugs, I think programmers (and their marketing people) were more focused on new features than performance
Thankfully we’ve moved past that era.
Now the bugs that get ignored for new features cause bad results AND bad performance.
It's not necessarily stupid code in the game, but something the C library is doing that it probably shouldn't.
If the stream is buffered, then all operations, including fread, are supposed to go through the buffer.
All three of these should issue buffer-sized reads to the operating system:
1. A loop which calls getc(stream) 65536 times.
2. fread(buf, 1, 65536, stream)
3. fread(buf, 65536, 1, stream)
The more direct behavior of fread should only kick in if the stream is configured as unbuffered.
I would say that the way low-level reads are issued to the host operating system is a "visible effect" of the program, so I suspect this may actually be a matter of conformance. I.e. it's not okay to issue those reads however the stream library wants as long as the data is read.