interesting take on memory management
hi guys,
I came across this post on hackerank, do you agree with his sentiment? let your opinions be known
I came across this post on hackerank, do you agree with his sentiment? let your opinions be known
| If a program is just about to terminate, not really. The OS is more efficient at cleaning up than you because it only has to mark pages as free. It doesn't have to touch each object and it can free paged out memory without paging it in. Of course, if you're holding database connections etc, then yes you want to explicitly deallocate those, and it may be better to explicitly deallocate everything than to try and pick and choose. But if it's just memory, leave it. |
The whole point of RAII is that resource management is encapsulated in the object, and the user doesn't need to worry about it.
The problem is that this post is too narrow in scope to be useful, and talking about the OS is just an implementation detail when it comes to handling resources within a program. It sounds like he's just talking about not calling delete on something that was new'd once in main(). Sure, such a use-case is trivial. But most things are more complicated than that. Or, if it isn't complicated now, it becomes harder to maintain later after code is refactored or added to. You don't know, in a limited scope, if a program is about to end.
Once you go into the limited scope of object, we now need to know precisely how that object is being used to know if we need to deal with deallocation to prevent memory leaks. In general, this isn't so simple to foresee, especially in a complicated project.
An object should free its resources when it's being destructed. It doesn't care if the program itself is about to end or not. (Of course, in fatal situations like exit, destructors aren't guaranteed to be called, but the program already received a fatal error at that point, so it's kinda moot.)
______________________________________
The OS might be "faster" because all it knows about is pools of heap data. It doesn't know what that data actually means. For example, not calling my_file_stream.close() in "managed" languages like Java can cause your file to not actually be written.
The problem is that this post is too narrow in scope to be useful, and talking about the OS is just an implementation detail when it comes to handling resources within a program. It sounds like he's just talking about not calling delete on something that was new'd once in main(). Sure, such a use-case is trivial. But most things are more complicated than that. Or, if it isn't complicated now, it becomes harder to maintain later after code is refactored or added to. You don't know, in a limited scope, if a program is about to end.
Once you go into the limited scope of object, we now need to know precisely how that object is being used to know if we need to deal with deallocation to prevent memory leaks. In general, this isn't so simple to foresee, especially in a complicated project.
An object should free its resources when it's being destructed. It doesn't care if the program itself is about to end or not. (Of course, in fatal situations like exit, destructors aren't guaranteed to be called, but the program already received a fatal error at that point, so it's kinda moot.)
______________________________________
The OS might be "faster" because all it knows about is pools of heap data. It doesn't know what that data actually means. For example, not calling my_file_stream.close() in "managed" languages like Java can cause your file to not actually be written.
Last edited on
No, it's a bad policy in practice.
If it was possible to keep perfect track of which resources need to be cleaned up and when, then this could work. However, resource management just so happens to be one of the most difficult problems a language and a programmer have to contend with. The more variables you add to the problem (what type of resources is this object holding? Why is the object being released?), the more likely it is that you're going to mess it up.
Don't worry about your process taking a little longer during clean-up. Do worry about your process leaking memory or other even more critical resources.
If it was possible to keep perfect track of which resources need to be cleaned up and when, then this could work. However, resource management just so happens to be one of the most difficult problems a language and a programmer have to contend with. The more variables you add to the problem (what type of resources is this object holding? Why is the object being released?), the more likely it is that you're going to mess it up.
Don't worry about your process taking a little longer during clean-up. Do worry about your process leaking memory or other even more critical resources.
Was it this?
https://www.hackerrank.com/challenges/virtual-functions/forum/comments/107860
All your program has to do is a silly simple thing and all you care is correctness of output and time to execute? Like MasterChef; you have very limited time to cook something and you don't care if it takes firefighters in HazMat suites to clean up the kitchen afterwards. No need to maintain the code / rebake the cake for years.
Real code cannot afford such shortcuts.
https://www.hackerrank.com/challenges/virtual-functions/forum/comments/107860
All your program has to do is a silly simple thing and all you care is correctness of output and time to execute? Like MasterChef; you have very limited time to cook something and you don't care if it takes firefighters in HazMat suites to clean up the kitchen afterwards. No need to maintain the code / rebake the cake for years.
Real code cannot afford such shortcuts.
| adam2016 wrote: |
|---|
| do you agree with his sentiment? let your opinions be known But if it's just memory, leave it. |
I think this applies to C (or extremely bad C++ written by a Java or C programmer). Even if I were writing a throwaway one-time toy program, in C++, i can't imagine making a pointer to "just memory" and leaving it naked. It takes extra mental effort compared to using a vector/pass-by-reference/etc
That said, the idea of releasing a large amount of heap memory without running destructors for every object sometimes comes up in real code, e.g. I hear some games do that to unload a level.
Last edited on
| That said, the idea of releasing a large amount of heap memory without running destructors for every object sometimes comes up in real code, e.g. I hear some games do that to unload a level. |
Oh really? Like OS calls that bypass C++ delete calls?
Last edited on
Even easier. Just mark the regions as free in your custom allocator and drop pointers.
Topic archived. No new replies allowed.