首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >给GC还是不给GC

给GC还是不给GC
EN

Stack Overflow用户
提问于 2011-09-27 20:09:46
回答 10查看 4.3K关注 0票数 70

最近,我看到了两个非常好的教育语言讲座:

由Herb编写的这是第一个展示了C++0x的所有漂亮和酷的特性,为什么C++的未来看起来比以往任何时候都要光明,以及在这个游戏中M$如何被认为是一个好人。讨论围绕效率和如何最小化堆活动经常改善性能。

另一个,由Alexandrescu,激励从C/C++过渡到他的新游戏改变D的大部分东西似乎真的很好的动机和设计。然而,有一件事让我感到惊讶,那就是D推动垃圾收集,所有的类都是通过引用创建的。更令人困惑的是,“D编程语言参考手册”一书在关于资源管理的一节中特别指出,引用如下:

垃圾收集消除了C和C++中必要的繁琐、容易出错的内存分配跟踪代码。这不仅意味着更快的开发时间和更低的维护成本,而且产生的程序经常运行更快的__!

这与Sutter关于最小化堆活动的不断讨论相冲突。我非常尊重萨特和亚历山德雷苏的见解,所以我对这两个关键问题感到有点困惑

  1. 仅仅通过引用创建类实例不就会导致大量不必要的堆活动吗?
  2. 在哪些情况下,我们可以在不牺牲运行时性能的情况下使用垃圾收集?
EN

回答 10

Stack Overflow用户

回答已采纳

发布于 2011-09-28 00:25:21

直接回答你的两个问题:

  1. 是的,通过引用创建类实例确实会导致大量堆活动,但是: 在D中,你有structclassstruct具有值语义,并且可以完成类所能做的一切,但多态性除外。 由于切片问题,多态和值语义从未很好地结合在一起。 在D中,如果您确实需要在堆栈上以一些性能关键的代码分配类实例,并且不关心安全性的损失,您可以通过scoped函数来做到这一点,而不会遇到不合理的麻烦。
  2. 在以下情况下,GC可以与手动内存管理媲美或比手动内存管理更快: 在可能的情况下,您仍然可以在堆栈上分配(通常在D中是这样的),而不是依赖堆进行所有操作(就像在其他GC'd语言中经常做的那样)。 b.您有一个顶级的垃圾收集器(诚然,D当前的GC实现有点幼稚,尽管在过去的几个版本中,它看到了一些重大的优化,因此它没有以前那么糟糕)。 你分配的大多是小物件。如果您分配了大部分大型数组,并且性能最终会出现问题,那么您可能希望将其中的几个转换到C堆(您可以访问C的malloc并在D中是空闲的),或者,如果它有作用域生存期,则需要一些其他的分配器,比如RegionAllocator。(目前正在讨论和改进RegionAllocator,以便最终纳入D的标准库)。 你不太关心空间效率。如果使GC运行得太频繁,以致内存占用量过低,那么性能将受到影响。
票数 45
EN

Stack Overflow用户

发布于 2011-09-27 20:23:46

在堆上创建对象比在堆栈上创建对象要慢,原因是内存分配方法需要处理堆碎片之类的事情。在堆栈上分配内存就像增加堆栈指针一样简单(一个固定时间的操作)。

然而,使用压缩的垃圾收集器,您不必担心堆碎片,堆分配可以和堆栈分配一样快。D编程语言的垃圾收集页面更详细地解释了这一点。

GC'd语言运行速度更快的断言可能是假设许多程序在堆上分配内存的频率比堆栈上高得多。假设在GC'd语言中堆分配可能更快,那么您刚刚优化了大多数程序的很大一部分(堆分配)。

票数 22
EN

Stack Overflow用户

发布于 2011-09-27 20:26:18

对1)的回答:

只要您的堆是连续的,在它上分配就像在堆栈上分配一样便宜。

最重要的是,当您分配彼此相邻的对象时,您的内存缓存性能将非常好。

只要您不必运行垃圾收集器,就不会丢失性能,堆将保持连续。

这是个好消息:)

回答2):

目前,GC技术有了很大的发展,甚至有了实时的应用.这意味着保证连续内存是一个由策略驱动的、依赖于实现的问题。

所以如果

  • 你可以买得起一个实时的gc
  • 应用程序中有足够的分配暂停。
  • 它可以让你的自由列表成为一个免费的块。

你可能会有更好的表现。

对未问问题的回答:

如果开发人员摆脱了内存管理问题,他们可能有更多的时间在代码中的实际性能和可伸缩性方面花费时间。这也是非技术因素起作用的原因。

票数 13
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/7575055

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档