c(pp)   56

« earlier    

c - What REALLY happens when you don't free after malloc? - Stack Overflow
keep this stuff in mind when writing competition stuff, can usually just omit deletes/frees unless you're really running up against the memory limit:
Just about every modern operating system will recover all the allocated memory space after a program exits.


On the other hand, the similar admonition to close your files on exit has a much more concrete result - if you don't, the data you wrote to them might not get flushed, or if they're a temp file, they might not get deleted when you're done. Also, database handles should have their transactions committed and then closed when you're done with them. Similarly, if you're using an object oriented language like C++ or Objective C, not freeing an object when you're done with it will mean the destructor will never get called, and any resources the class is responsible might not get cleaned up.


I really consider this answer wrong.One should always deallocate resources after one is done with them, be it file handles/memory/mutexs. By having that habit, one will not make that sort of mistake when building servers. Some servers are expected to run 24x7. In those cases, any leak of any sort means that your server will eventually run out of that resource and hang/crash in some way. A short utility program, ya a leak isn't that bad. Any server, any leak is death. Do yourself a favor. Clean up after yourself. It's a good habit.


Allocation Myth 4: Non-garbage-collected programs should always deallocate all memory they allocate.

The Truth: Omitted deallocations in frequently executed code cause growing leaks. They are rarely acceptable. but Programs that retain most allocated memory until program exit often perform better without any intervening deallocation. Malloc is much easier to implement if there is no free.

In most cases, deallocating memory just before program exit is pointless. The OS will reclaim it anyway. Free will touch and page in the dead objects; the OS won't.

Consequence: Be careful with "leak detectors" that count allocations. Some "leaks" are good!
q-n-a  stackex  programming  memory-management  performance  systems  c(pp)  oly-programming 
7 days ago by nhaliday

« earlier    

related tags

abstraction  advice  algorithms  analysis  api  assembly  benchmarks  best-practices  blog  books  brands  build-packaging  cheatsheet  checking  clojure  code-dive  commentary  comparison  compilers  computer-vision  concurrency  contrarianism  cool  critique  crypto  data-science  data  database  dataset  dbs  debate  debugging  deep-learning  desktop  devtools  discussion  distributed  documentation  editors  embedded  engineering  erlang  explanation  facebook  formal-methods  forum  functional  gender  git  golang  gotchas  graphics  guide  haskell  hmm  hn  howto  human-ml  ide  idk  infographic  init  javascript  jvm  language  let-me-see  libraries  linear-models  links  linux  list  llvm  lol  long-short-run  machine-learning  matching  matrix-factorization  memory-management  metrics  model-class  multi  networking  nitty-gritty  nlp  numerics  objektbuch  ocaml-sml  oly-programming  oly  org:edu  org:junk  org:med  os  oss  osx  papers  paste  pdf  performance  philosophy  pic  planning  pls  plt  pragmatic  prediction  presentation  programming  project  protocol  python  q-n-a  qra  quiz  quora  ranking  recommendations  reference  reflection  rhetoric  rsc  rust  scale  scaling-tech  security  shipping  software  stackex  startups  stats  stream  summary  system-design  systems  tech  techtariat  terminal  threat-modeling  tools  top-n  trends  trivia  tutorial  ui  unit  unix  video  visualization  wiki  workflow  working-stiff  yak-shaving  🖥 

Copy this bookmark: