home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12368 < prev    next >
Encoding:
Text File  |  1992-08-14  |  3.2 KB  |  65 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!news.mentorg.com!bcannard
  3. From: bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565)
  4. Subject: Re: Garbage Collection for C++
  5. Originator: bcannard@hppcb36
  6. Sender: news@news.mentorg.com (News User)
  7. Message-ID: <1992Aug15.025613.4571@news.mentorg.com>
  8. Date: Sat, 15 Aug 1992 02:56:13 GMT
  9. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug13025629@synaptx.synaptics.com> <TMB.92Aug14130323@arolla.idiap.ch>
  10. Nntp-Posting-Host: 134.86.73.85
  11. Organization: Mentor Graphics 
  12. Keywords: 
  13. Followup-To: 
  14. Lines: 49
  15.  
  16.  
  17. In article <TMB.92Aug14130323@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  18. |> In article <1992Aug14.021547.15215@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
  19. |> 
  20. |>    In article <DAVEG.92Aug13025629@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
  21. |>    |> Couldn't we get away with having a garbage collector that didn't
  22. |>    |> need pointers to be declared `GC'?
  23. |> 
  24. |>    I can't see that this is viable given the basic constraints on C++: among
  25. |>    other things, those who don't want GC shouldn't have to suffer the hits.
  26. |> 
  27. |> What "hits"? In all the cases that I have looked at, the GC overhead
  28. |> has been _smaller_ than the overhead of explicit memory management in
  29. |> C++. Now, maybe my sample of programs is biased, but if you claim that
  30. |> there are "hits", please state either whether you have concrete
  31. |> evidence that there are, or whether your statement is just religious
  32. |> belief. Your vague statements might easily turn into gospel truth.
  33. |> 
  34. |> Based on my experience, I would turn your statement around and say:
  35. |> "those of us who want GC shouldn't have to suffer the inefficiencies
  36. |> of not having it".
  37. |> 
  38. |>                     Thomas.
  39.  
  40. It's practical experience. A question for you: have you ever used a
  41. custom-made, tailored new/delete (or malloc/free), instead of the ones provided
  42. as standard? I have. I've been inside malloc (it's not a pretty sight :-) ),
  43. worked around it, optimised it, jiggled the numbers, bypassed it, and generally
  44. done everything I could to optimise storage recycling. The difference in
  45. performance (on the right type of application) is startling, and more than the
  46. difference between manual and automatic. I'm willing to talk at greater length
  47. about storage allocation, if people are interested, but I'd rather do it in a
  48. different thread, or off-line.
  49.  
  50. In a *fair* comparison between an optimised GC and an optimised
  51. manual scheme, the manual scheme will win if the decision of when and what to
  52. delete can be made at compile time. In a situation where the decision can only
  53. be made at run time, the GC will win. This is one reason why I want both
  54. mechanisms.
  55.  
  56. There are plenty of reasons whey GC is genuinely more efficient than
  57. manual: it allows better-designed data structures, it eliminates the need to
  58. copy data which plagues large systems using manual recycling, and it reduces
  59. development and maintenance costs. But the idea that GC is inherently faster
  60. than manual is bogus.
  61. -- 
  62. bob_cannard@mentorg.com         "Human beings? ... Well, I suppose they are a
  63.                                  form of life, even if they are unspeakable"
  64. Exprssed opinions are not necessarily those of Mentor Graphics Corporation.
  65.