style 表的结构化访问

我们游戏 UI 基于 RmlUI 的 fork,做了大量的改造。它实际上类似目前的 web 前端技术,使用 CSS 来表示 UI 的布局。所以,我们做的底层工作也都是围绕如何高效实现一套基于 CSS 的 UI 引擎来做的。

一年多前,我写过一篇 blog 介绍了一些优化的工作。

最近,在游戏开发的使用中,我们又发现了一些性能热点,最近在着手优化。这一篇 blog 记录一下其中的一个优化点。

按目前引擎的抽象,每个 style 其实是一组 attrib 的列表。而单个 attrib 则是一个 k/v 对。k 虽然使用上是一个字符串,但实际上会被转换为 [0,127] 的数字 id 。也就是说,引擎只支持一百来个不同的 key 。就目前 RmlUI 定义的 css 规范来说,够用了。

而 value ,也是一个字符串。但对于不同的 key 有不同的结构。对 stylecache 模块来说,它并不关心其结构,全部视为字符串。这个字符串根据不同的 key ,可能是布尔量、数字、字符串、也可以是一组数字、甚至是一个字典这类复杂结构。

RmlUI 是用 C++ 编写的,我们把 style 从字符串取出时,转换为一个 C++ 可以方便访问的类。过去,这是通过序列化和反序列化进行的。即,当我们把 attrib 从 style 中取出时,将 attrib 通过反序列化变成一个 C++ 对象。这个对象可以方便的被 C++ 代码使用。

目前,这个反序列化过程发现有潜在的性能问题,值得优化一下。大致有两个方向:

其一,直接把 C++ 对象映射为连续内存,然后将内存视为字符串被 stylecache 管理起来。这样,就省去了反序列化的过程,也无需在每次访问 attrib 的数据时构造新的 C++ 对象(这个对象可以视为数据块的访问器)。

这一步我们已经差不多做好了,的确提升了不少性能。

但是复杂结构,比如字典对象,就很难被映射到连续内存块中。这是因为,复杂数据结构需要额外的索引信息。这些信息在 C++ 语境下,很可能是一些指针。指针是很难被复制和移动的,它难以被视为字符串。

所以,我考虑了第二个方向:不拒绝额外的访问器对象,同时对访问器做缓存。

如果我们把一个复杂的数据结构看成有两种形态,一是一个字符串;二是一个 C++ 对象;两者的信息是完全等价的,当它们都是不变量时,后者就是前者的访问器。

如果 C++ 对象可以通过字符串调用反序列化接口创建出来,又可以调用序列化接口变成一个字符串,那么就可以在两个心态间自由转换。通过这种转换,我们可以简化信息本身的生命期管理。

字符串的优势是可以自由的制作副本,计算 hash ,去重,比较等等;劣势是难以访问内部的数据子结构。

所以,我们对外的接口提到 attrib 时均可以 C++ 对象的形式提供数据,这样可以方便用户数据其内部数据结构。但,当我们需要在内部储存一个 attrib ,则可以以序列化后的字符串形式保存下来,同时 cache 一个对应的 C++ 访问器对象的内部 handle。这个 handle 可以较小,例如,当我们使用一个 16bit handle 时,内部其实最多 cache 64K 个访问器。因为访问器和字符串数据可以自由转换,当 cache 失效时,随时都能重建。

注意,这里没有提到访问器对象的生命期管理。实际上,我们需要调用者提供一个销毁方法,这样才能在 cache 满后销毁掉不用的访问器。但用户完全可以额外给访问器增加引用计数的管理。它的好处是,当通过接口取得一个 attrib 的访问器后,可以通过增加引用来持有它,下次把这个对象再重新传回 stylecache 模块(同时减一次引用)。持有和复用特定 attrib 的成本就是 O(1) 的了。

即:如果从外部传入一个新的 attrib ,stylecache 模块先把它序列化为字符串,持有这个字符串,这样就无需和外部商定其生命期如何管理(信息被复制了一次)。

如果从 stylecache 获取一个 attrib ,得到的是一个生命期仅延续到下一次 api 调用前的访问器,用户不需要关心它的生命期。但接下来如何立刻将访问器指针传回 stylecache 模块,则有可能在内部 cache 中找到,这样就可以跳过序列化流程。零拷贝。

大致是这样的,用户先定义三个接口:

typedef void * accessor_t;  // 访问器,可以是一个 C++ 对象

accessor_t (*create)(const char *, size_t);  // 从字符串构造访问器
void (*release)(accessor_t);  // 销毁访问器
size_t (*serialize)(accessor_t, char buf[], size_t buf_sz);  // 将访问器序列化为字符串

style 层面的接口需要交换 attrib 数据时,都采用访问器类型。所有的接口都约定为:对于输入参数,调用者自己负责输入访问器的生命期;对于输出参数,返回的访问器对象的生命期至少可以维持到下一个 api 调用。这样即没有增加生命期管理的成本,又可以额外提供一个 C++ 访问器对象供用户使用。

我写这篇 blog 是因为觉得以上方案有一定的通用性,值得记录一下:

在以往的 C++ 方案中,如果你想将一个 C++ 对象视为一个基础类型,常见的方案是给它定义一大堆接口:增加引用、减少引用、复制、计算 hash 、对象比较……

这样,这个对象才能被传递、复制、储存在容器中,以及作为字典的 key ,做类似字符串 intern 这样的去重(即相同的值在系统中只保留一份)。

我觉得传统方案过于复杂,需要额外编写大量的代码,且在生命期管理上很容易犯错。而这篇提到的方法,只需要为对象实现序列化、反序列化以及销毁三个接口就够了。而且减少了生命期管理的复杂度。

文章来源:

Author:云风
link:https://blog.codingnow.com/2024/01/style_attrib_access.html