Vala生成的C代码优于手写C代码有多少优化？

Question

Vala生成的代码是否像普通的手写C代码一样进行了优化？使用GObject系统而不使用它有任何性能开销吗？

注意:在我的下一个C项目中,我正在研究是否使用Vala.该项目不是GUI应用程序,它是一种解释器类型的应用程序,必须与平台无关.我使用gcc作为编译器.

Answer 1

作为Vala开发人员,我不建议使用Vala作为翻译.在解释器中,您将为ast,数据类型,可能的中间对象,codegen对象等创建许多对象.在Vala本身,我个人测量了主要的开销是创建对象(简单的GTypeInstance,甚至不是GObject).Vala旨在与gobjects一起使用,但gobjects的设计并不是为了快速分配.

所以,对于你的项目,我仍然会使用glib/gio来处理跨平台的东西,比如网络,字符串工具,unicode,数据结构等,因为它们有一个干净,一致和方便的API,但我不会创建ast对象作为gobjects/gtypeinstance.在翻译中你需要快速分配,这就是重点.

我个人的建议是:如果你想构建桌面应用程序,dbus服务,gstreamer东西或任何触及g*世界的东西,请使用vala,没有别的.

Answer 2

这取决于你写C的内容.特别是:

• 既然我可以手工编写基于GObject的C代码,那么你的门槛是多少？手写的基于GObject的C与Vala编写的基于GObject的C？可能具有可比性,因为Vala将产生或多或少与人类相同的库调用.
• GObject类在技术上是可选的.您可以将类标记为[Compact]跳过类的所有GLib代码生成,这将更快,但如果您这样做,您将失去许多功能,例如虚拟方法.这仍然会比用C编写的对象略微增加开销,但它带有线程安全引用计数和一些典型的C程序员不会打扰的其他事情.
• Vala会生成很多临时变量.如果您的C编译器完全具有优化功能,那么大多数这些临时工具都将被淘汰.Vala的大部分控制结构与其C计数器部件相匹配,因此Vala if不会比C更昂贵if.
• Vala跟踪引用以在编译时进行内存管理.通常,这很便宜,但它可能导致数组和字符串的额外重复.特别是,如果将无主字符串复制到已拥有的变量,strdup则会自动调用.这意味着生成的Vala将创建更多这些小的临时对象,但是,如果它确实存在问题,您可以明智地使用它unowned来限制它们的创建.