On Friday, 22 December 2023 at 16:51:11 UTC, bachmeier wrote:
Given how fast computers are today, the folks that focus on
memory and optimizing for performance might want to apply for
jobs as flooring inspectors, because they're often solving
problems from the 1990s.
*Generally* speaking, I disagree. Think of the case of GTA V
where several *minutes* of loading time were burned just because
they botched the implementation of a JSON parser.
Of course, this was unrelated to memory management. But it goes
to show that today's hardware being super fast doesn't absolve
you from knowing what you're doing... or at least question your
implementation once you notice that it's slow.
But that is true for any language, obviously.
I think there is a big danger of people programming in C/C++ and
thinking that it *must* be performing well just because it's
C/C++. The C++ codebase I have to maintain in my day job is a
really bad example for that as well.
I say this as I'm in the midst of porting C code to D. The
biggest change by far is deleting line after line of manual
memory management. Changing anything in that codebase would be
miserable.
I actually hate C with a passion.
I have to be fair though: What you describe doesn't sound like a
problem of the codebase being C, but the codebase being crap. :)
If you have to delete "line after line" of manual memory
management, I assume you're dealing with micro-allocations on the
heap - which are performance poison in any language.
A decent system would allocate memory in larger blocks and manage
access to it via handles. That way you never do micro-allocations
and never have ownership problems.
Essentially, it's still a "memory manager" that owns all the
memory, the only difference being that it's self-written.
Porting a codebase like that would actually be very easy because
all the mallocs would be very localized.
Of course, this directly leads to the favorite argument of C
defenders, which I absolutely hate: "Why, it's not a problem if
you're doing it *right*."
By this logic, you have to do all these terrible mistakes while
learning your terrible language, and then you'll be a good
programmer and can actually be trusted with writing production
software - after like, what, 20 years of shooting yourself in the
foot and learning everything the hard way? :)
And even then, the slightest slipup will give you dramatic
vulnerabilities.
Such a great concept.
