4 ms·

What's the advantage to deallocating on exit?

by eutectic 10y ago

ktRolster 10y ago
You know your code is clean.
- luckydude 10y ago
  Hi, BitKeeper guy here (BK predates git, first distributed SCM). I built what I'm sure is a less good version of this, I called it purify, you included purify.h and it warned you about all the stuff that it could by redefining malloc/free/etc to ones that kept track of stuff. So some overlap with the system posted here. We were very careful to free everything before exit. It just felt cleaner. It was also a bad idea. Until a few years ago, BK used an ascii file format, which means it read in the graph with all the meta data, parsing that, malloc-ing each string, each struct, etc. At exit we carefully freed all that. Why was that a bad idea? If you wanted to link BK into your long lived IDE or wanted it to be a library, then it was a very good idea. But we never did that and BK doesn't really want to be used that way. So it became a performance problem. Consider bk changes -1 # same as git log -1 That used to parse the entire changeset graph, build an in memory one version of it, find the tip (HEAD), print out the comment, then recursively free everything. All for the holy grail of "knowing your code is clean". Clean is good unless it is pointless. Another way to say the same thing is you could make the claim that all code should be written to be thread safe. Even if you never multi thread it. That's a lot of work, maybe not so bad for people who are good at threading, but it's work for most people (I'm a former Sun kernel hack, I get threads, it's not that hard once you get over the hump but a lot of people don't). If you have no intention of multi threading the code then making it thread safe is just "clean code" masturbation. I'm all for clean code stuff where you are going to reap some value. In our case we did all that clean code memory management and eventually said screw that, changed the file format so we could mmap() it and page it in (read/write protect everything, take the fault, fault handler pages it in). No alloc, no free, way better performance. All those years of clean code bought us nothing. I get that if you are making a library the rules about clean are very very different. But for an app that is going to run and exit, don't push clean down people's throat, it isn't helping in a lot of cases.
  - _0ffh 10y ago
    upvote because thanks for taking the time!
- eutectic 10y ago
  This seems like cargo-cultism. How is doing something redundant and potentially harmful just to conform to a general guideline any cleaner than exercising judgement?
  - ktRolster 10y ago
    I'm intrigued that you feel so strongly about this. I therefore refer you to this comment: https://news.ycombinator.com/item?id=12710990 https://news.ycombinator.com/item?id=12710990
_0ffh 10y ago
The good feeling of having cleaned your house before it gets sucked into a black hole :)

What's the advantage to deallocating on exit?

ktRolster 10y ago

You know your code is clean.

luckydude 10y ago
Hi, BitKeeper guy here (BK predates git, first distributed SCM). I built what I'm sure is a less good version of this, I called it purify, you included purify.h and it warned you about all the stuff that it could by redefining malloc/free/etc to ones that kept track of stuff. So some overlap with the system posted here. We were very careful to free everything before exit. It just felt cleaner. It was also a bad idea. Until a few years ago, BK used an ascii file format, which means it read in the graph with all the meta data, parsing that, malloc-ing each string, each struct, etc. At exit we carefully freed all that. Why was that a bad idea? If you wanted to link BK into your long lived IDE or wanted it to be a library, then it was a very good idea. But we never did that and BK doesn't really want to be used that way. So it became a performance problem. Consider bk changes -1 # same as git log -1 That used to parse the entire changeset graph, build an in memory one version of it, find the tip (HEAD), print out the comment, then recursively free everything. All for the holy grail of "knowing your code is clean". Clean is good unless it is pointless. Another way to say the same thing is you could make the claim that all code should be written to be thread safe. Even if you never multi thread it. That's a lot of work, maybe not so bad for people who are good at threading, but it's work for most people (I'm a former Sun kernel hack, I get threads, it's not that hard once you get over the hump but a lot of people don't). If you have no intention of multi threading the code then making it thread safe is just "clean code" masturbation. I'm all for clean code stuff where you are going to reap some value. In our case we did all that clean code memory management and eventually said screw that, changed the file format so we could mmap() it and page it in (read/write protect everything, take the fault, fault handler pages it in). No alloc, no free, way better performance. All those years of clean code bought us nothing. I get that if you are making a library the rules about clean are very very different. But for an app that is going to run and exit, don't push clean down people's throat, it isn't helping in a lot of cases.
- _0ffh 10y ago
  upvote because thanks for taking the time!
eutectic 10y ago
This seems like cargo-cultism. How is doing something redundant and potentially harmful just to conform to a general guideline any cleaner than exercising judgement?
- ktRolster 10y ago
  I'm intrigued that you feel so strongly about this. I therefore refer you to this comment: https://news.ycombinator.com/item?id=12710990 https://news.ycombinator.com/item?id=12710990

_0ffh 10y ago

The good feeling of having cleaned your house before it gets sucked into a black hole :)