使用OpenGL Loader Generator优于GLEW的性能优势？

标题几乎解释了这一切。昨天我在浏览Stack的时候第一次听说了这个项目，我查看了一下它，以了解它相对于Stack的优势。在项目网站上，他们声明：

此加载程序生成系统用于创建OpenGL标题和 为您的特定需求加载代码。而不是得到每一个 扩展和核心枚举器/函数都集成在一个大标题中，您可以 只得到你真正想要和要求的

---

虽然我知道这种方法肯定比GLEW更简洁，但我不明白这种方法如何提高编译时间、应用程序性能或与OpenGL驱动程序的交互。此外，使用它的过程似乎需要更多的维护，因为每次需要使用额外的扩展时都必须重新生成扩展源。我从来没有注意到在使用GLEW时（与不使用相比）有任何性能下降，所以我很好奇为什么这个项目的开发人员觉得他们有问题要解决。我遗漏了什么吗？

我认为没有明显的性能提升，但使用OpenGL函数声明可以得到更小的头文件/源文件

GLEW/GLEE在库中有所有版本组合+扩展，这使得它相当大。例如，GLEW 1.7的头文件有834kb

---

OpenGL加载程序为所需的OpenGL版本生成自定义文件。这些文件要小得多（例如，核心opengl 4.2的头文件大约为120kb+130kb源文件）。这将使编译速度大大快于GLEW库，当然它的输出代码也更小。

为了充分公开，我编写了opengl Loader生成器

虽然我知道这种方法肯定比GLEW更简洁，但我不明白这种方法如何提高编译时间、应用程序性能或与OpenGL驱动程序的交互

这是一个OpenGL函数加载库。除了样式中的内联转发函数之外，它只是调用函数指针。就像GLEW一样

两者之间唯一可能的性能差异是加载这些函数所需的时间（即：初始化例程）。由于这是一个初始化函数，其一次性性能是无关的，除非它非常慢

简言之，该工具的目的不是为了提高“应用程序性能或与OpenGL驱动程序的交互”。它的存在是为了有清晰的标题，这些标题准确且仅包含您打算使用的OpenGL部分。此外，它还允许您轻松地使用GLEW或GLee样式的函数初始化，如您所认为合适的那样

关于编译时间的性能，我认为编译一个100kb的头比一个800 kb的要便宜。但是因为GLW和我的工具都不使用高级的C++技术，比如元编程或模板，所以任何编译时间的节省都是很小的。 此外，使用它的过程似乎需要更多的维护，因为每次需要使用额外的扩展时都必须重新生成扩展源

这当然是使用该工具的一种方法。使用该工具的另一种方法是提前找出适合您的扩展，然后使用它们

一般来说，当你编写真正的OpenGL应用程序时，你要针对特定的OpenGL版本编写代码。这个版本由你想要支持的最低硬件决定。如果你想支持从过时的Intel 945“GPU”到AMD和NVIDIA的最新高端产品的所有东西，你必须针对GL 1.4编写（可能是2.1版，如果你真的很勇敢，并且愿意对英特尔驱动程序进行大量测试的话）。如果你想支持更新的硬件，你可以针对OpenGL 3.x版本中的一个编写代码，3.1版取决于你想给英特尔GPU的支持程度

从那里，您可以决定要支持哪些更高版本的可选功能，或者只是硬件特定的功能。您有一个要使用的内容列表，因此您可以检查这些扩展，并根据需要有条件地使用或不使用它

这就是这个工具的用途：当你确定了一组特定的扩展和OpenGL版本。如果你想更灵活，你可以生成一个包含更多扩展的标题，即使你不使用它们。或者你可以使用GLEW；我的工具是一个选项，而不是一个要求

这个工具并不是为每个人准备的，它是为那些知道自己想要什么，想要不包含标题的人准备的

它还适用于自动完成等功能。有了干净的标题，您必须筛选的垃圾邮件要少得多，而您根本不打算调用这些垃圾邮件。哦，这有助于防止您意外使用某个扩展名中的某个内容，而您忘了检查该扩展名。因为它不在标题中，因此任何调用此类函数或使用这些枚举的尝试都会失败导致编译器错误

另一个好处是易于使用。请看。这部分是因为GLEW可以编译为静态或动态库。因此，您必须在代码中使用

#define

在它们之间切换（在Windows上）。这很糟糕

使用生成器，您只需在常规构建中粘贴头文件和源文件。无需构建或链接库。只需几个额外的头文件和源文件

---

这就是我编写该工具的原因。

这是一个很好的比较。它是由glLoadGen作者编写的。生成器和glload之间有什么关系吗？@KillianDS:嗯，我正在使用的当前GLSDK版本使用生成器生成glload。但实际上它非常乱伦；我在glload f的代码生成中所做的工作然后我将其后传入glLoad。