Ruby在某些方面很慢.但它的哪些部分最成问题？
垃圾收集器对性能有多大影响？我知道有时候单独运行垃圾收集器需要几秒钟,特别是在使用OpenGL库时.
我使用Ruby的矩阵数学库特别慢.ruby如何实现基本数学有问题吗？
Ruby中是否有任何动态特性无法有效实现？如果是这样,Lua和Python等其他语言如何解决这些问题呢？
最近的工作是否已经显着提高了性能？
Ruby很慢.但它的哪些部分最成问题？
它对方法进行"延迟查找",以实现灵活性.这会减慢它的速度.它还必须记住每个上下文的变量名称以允许eval,因此它的帧和方法调用较慢.它目前缺少一个好的JIT编译器,虽然MRI 1.9有一个字节码编译器(更好),jruby将它编译成java字节码,然后(可以)通过HotSpot JVM的JIT编译器进行编译,但它最终是关于速度与1.9相同.
垃圾收集器对性能有多大影响？我知道有时候单独运行垃圾收集器需要几秒钟,特别是在使用OpenGL库时.
从http://www.igvita.com/2009/06/13/profiling-ruby-with-googles-perftools/的一些图表中我可以说它需要大约10% - 这是相当多的 - 你可以通过增加gc.c中的malloc_limit并重新编译来减少该命中.
我使用Ruby的矩阵数学库特别慢.ruby如何实现基本数学有问题吗？
Ruby 1.8"没有"实现它实现的基本数学数字类,你每次调用就会调用像Fixnum#+ Fixnum#/一样的东西 - 这很慢.Ruby 1.9通过内联一些基本的数学操作来作弊.
Ruby中是否有任何动态特性无法有效实现？如果是这样,Lua和Python等其他语言如何解决这些问题呢？
像eval这样的东西很难有效地实现,虽然可以做很多工作,我敢肯定.Ruby的踢球者是它必须适应另一个线程中的某个人自发地改变一个类的定义,所以它必须非常保守.
最近的工作是否已经显着提高了性能？
1.9就像一个2倍的加速.它也更节省空间.JRuby不断尝试提高速度[并且可能在GC中花费的时间少于KRI].除此之外,除了我一直在努力的小事情之外,我并没有意识到这一点.另请注意,由于编码友好性,1.9的字符串有时会变慢.
Ruby非常适合快速提供解决方案.提供快速解决方案的效果较差.这取决于你想要解决的问题.我想起了90年代早期关于旧CompuServe MSBASIC论坛的讨论:当被问及哪个更快的Windows开发,VB或C时,通常的答案是"VB,大约6个月".
在其MRI 1.8形式中,Ruby相对来说执行某些类型的计算密集型任务相对较慢.与大多数主流编译语言相比,几乎任何解释语言都会受到这种影响.
原因有几个:一些相当容易解决(例如1.8中的原始垃圾收集),有些则不那么容易.
1.9解决了一些问题,尽管它可能需要一段时间才能普遍使用.针对预先存在的运行时的一些其他实现,例如JRuby,IronRuby,MagLev,有可能明显更快.
关于数学性能,看到相当慢的吞吐量我不会感到惊讶:它是你为任意精度支付的价格的一部分.再次,选择你的问题.我已经解决了Ruby中70多个Project Euler问题,几乎没有解决方案需要花费超过一分钟才能运行.你需要多快才能运行它需要多快？
最有问题的部分是"每个人".
如果"每个人"都没有真正使用该语言,那么奖励积分.
说真的,1.9更快,现在与python相提并论,jruby比jython更快.
垃圾收集器无处不在; 例如,Java有一个,它在动态内存处理方面比C++更快.Ruby不适合数字运算; 但是很少有语言,所以如果你的程序中有任何语言的计算密集型部分,你最好用C语言重写它们(由于它的原始类型,Java在数学方面很快,但它为它们付出了很大的代价,它们显然是# 1在语言中最丑陋的部分).
至于动态功能:它们并不快,但静态语言中没有它们的代码甚至可能更慢; 例如,java将使用XML配置而不是使用DSL的Ruby; 因为XML解析成本很高,所以可能会很慢.
嗯 - 几年前我参与了一个项目,在那里我用Ruby性能刮掉了桶,我不确定自那以后有多少变化.现在它是一个警告 - 你必须知道不做某些事情,坦率地说游戏/实时应用程序将是其中之一(因为你提到OpenGL).
杀死交互性能的罪魁祸首是垃圾收集器 - 其他人在这里提到Java和其他环境也有垃圾收集,但Ruby必须阻止世界运行.也就是说,它必须停止运行程序,从头开始扫描每个寄存器和内存指针,标记仍在使用的内存,然后释放剩下的内存.发生这种情况时,不能中断该过程,正如您可能已经注意到的那样,可能需要数百毫秒.
它的执行频率和执行长度与您创建和销毁的对象数量成正比,但除非您完全禁用它,否则您无法控制.我的经验是有几个令人不满意的策略来平滑我的Ruby动画循环:
GC.disable/GC.enable围绕关键的动画循环,也许是一个机会主义的GC.start,当它不会造成任何伤害时强制它去.(因为当时我的目标平台是一台64MB的Windows NT机器,这导致系统偶尔会耗尽内存.但从根本上说这是一个坏主意 - 除非你可以预先计算出在执行此操作之前可能需要多少内存, '冒着内存耗尽的风险)
减少您创建的对象数量,这样GC可以减少工作量(减少执行的频率/长度)
在C中重写你的动画循环(一个警察出来,但是我带的那个!)
这些天我可能还会看到JRuby是否可以作为替代运行时,因为我相信它依赖于Java更复杂的垃圾收集器.
我发现的另一个主要性能问题是在一段时间内尝试在Ruby中编写TFTP服务器时的基本I/O(是的,我为我的性能关键项目选择了所有最好的语言,这只是一个实验).简单地响应一个UDP数据包与另一个UDP数据包的绝对最简单的循环,包含下一个文件,必须比库存C版本慢大约20倍.我怀疑在使用低级IO(sysread等)的基础上可能会有一些改进,但速度可能只是因为没有低级字节数据类型 - 每个小读取都被复制到一个串.这只是猜测,我没有进一步采取这个项目,但它警告我不依赖于快速的I/O.
虽然我在这里没有完全更新,但最近增长的主要速度是虚拟机实现重做1.9,从而加快了代码执行速度.但是我认为GC没有改变,我很确定I/O方面没什么新东西.但是我并没有完全了解最前沿的Ruby,所以其他人可能想要在这里筹码.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
