基于访问者模式的嵌入式序列化库内存膨胀问题与优化咨询

问题背景 #

我正在为嵌入式目标开发一个基于经典访问者模式的序列化库，每个需要序列化的结构体都实现了模板化的pack()方法，示例如下：

struct softwareInfo
{
    uint32_t version;
    std::array<uint8_t, 40> commitHash;
    uint32_t buildDate;

    template <class T>
    void pack(T& archive)
    {
        archive.process(HVP(version));
        archive.process(HVP(commitHash));
        archive.process(HVP(buildDate));
    }
};

HVP宏会将字段及其哈希名称打包到后续使用的hashValuePair类中，具体实现如下：

constexpr uint32_t compileTimeHash(const char* str, size_t index = 0, uint32_t hash = 0)
{
    return (str[index] == '\0') ? hash : compileTimeHash(str, index + 1, hash * 31 + str[index]);
}

template <typename T>
class hashValuePair
{
   public:
    hashValuePair(uint32_t hash, T* value) : hash(hash), value(value) {}
    uint32_t getHash() const { return hash; }
    T& getValueRef() { return *value; }

   private:
    uint32_t hash = 0;
    T* const value = nullptr;
};

#define HVP(var) hashValuePair(compileTimeHash(#var), &var)

该库包含另外两个模块：

1. PersistentStorage类：用于注册可序列化对象，它持有如下缓冲区：

std::array<StorageEntry, maxEntries> entries

其中StorageEntry、EntryBase及Entry模板类的定义如下：

struct StorageEntry
{
    std::aligned_storage_t<sizeof(Entry<void>), alignof(Entry<void>)> buffer;
    EntryBase* object;
    struct Header
    {
        uint32_t hashName;
        uint32_t size;
    } header;
    uint32_t datacrc32;
    Status packStatus;
    Status unpackStatus;
};

class EntryBase
{
   public:
    virtual ~EntryBase() {}
    virtual void pack(Packer::Packer& packer) = 0;
    virtual void pack(Packer::Unpacker& unpacker) = 0;
};

template <typename T>
class Entry : public EntryBase
{
   public:
    explicit Entry(T* item) : item(item) {}
    void pack(Packer::Packer& packer) override { item->pack(std::forward<Packer::Packer&>(packer)); }
    void pack(Packer::Unpacker& unpacker) override { item->pack(std::forward<Packer::Unpacker&>(unpacker)); }

   private:
    T* const item;
};

该类包含doRead()和doWrite()两个核心方法，会遍历所有注册的结构体，通过下文的pack/unpack方法完成序列化/反序列化。

2. Packer/Unpacker类对：用于通过process方法遍历成员，完成结构体的序列化与反序列化，实现如下：

namespace Packer
{

class Packer
{
   public:

    template <class T>
    void process(hashValuePair<T>&& hashValuePair)
    {
        packType(hashValuePair.getValueRef());
    }

   private:

    template <class T>
    void packType(T& value)
    { 
        (...)
        copyToBuf(value);
    }

    template <class T>
    void copyToBuf(T value)
    {
        it += serialize<T>(value, it);
    }
};

class Unpacker
{
   public:

    template <class T>
    void process(hashValuePair<T>&& hashValuePair)
    {
        //search for value hash
        unpackType(hashValuePair.getValueRef());
    }

   private:

    template <class T>
    void unpackType(T& value)
    {
        (...)
        tryUnpack(*it++, value);
    }

    template <typename T>
    void tryUnpack(uint8_t maybeType, T& value)
    {
        if (maybeType != getType(value))
            //error
        copyToValue(value);
    }

    template <typename T>
    void copyToValue(T& value)
    {
        value = deserialize<T>(it);
        it += sizeof(value);
    }
};

template <class PackableObject>
Status pack(PackableObject& obj, std::span<uint8_t>& buf, size_t& packedSize)
{
    Status status{};
    auto packer = Packer(buf, packedSize, &status);
    obj.pack(packer);
    return status;
}

template <class PackableObject>
Status unpack(PackableObject& obj, std::span<uint8_t>& buf)
{
    Status status{};
    auto unpacker = Unpacker(buf, &status);
    obj.pack(unpacker);
    return status;
}

} 

我有意省略了错误处理、哈希查找等其他实现部分，仅保留核心流程。

目前我发现该实现的内存占用相对较高：例如序列化softwareInfo结构体占用了464B的FLASH内存；当新增一个uint32_t字段时，FLASH占用会增加44B，这一增量过大，且编译已使用-Os的release模式。

请问当前设计存在哪些明显缺陷？使用std::variant这类运行时多态工具能否缓解该问题？

问题解答 #

当前设计的明显缺陷 #

• 模板实例化导致代码膨胀：每个可序列化结构体的pack()模板方法，会为Packer和Unpacker分别生成独立的实例；同时process、packType等模板方法，也会为每个字段的类型生成专属代码。即使是相同类型的字段（如多个uint32_t），编译器也可能无法完全合并重复实例，造成FLASH中冗余代码堆积。
• 虚函数体系的额外开销：EntryBase的继承结构会为每个Entry<T>子类生成独立的虚函数表（vtable），每个StorageEntry还需持有基类指针，加上std::aligned_storage_t的对齐冗余，进一步增加静态内存占用；虚函数的实现代码也会额外消耗FLASH空间。
• 字段绑定的冗余逻辑：HVP宏为每个字段生成hashValuePair临时对象，虽然哈希是编译期计算，但process方法处理字段时的模板实例化，会把字段类型、哈希处理逻辑等以代码形式固化，而非紧凑的数据形式。新增字段时，不仅要添加字段本身的序列化代码，还要引入新的模板实例，这就是新增uint32_t字段导致44B增量的核心原因——远大于字段本身的4B。
• 序列化元数据冗余：从代码逻辑看，序列化时可能为每个字段存储了哈希值、类型标识等元数据，这些信息会大幅增加FLASH中存储的序列化数据体积，字段越多，元数据的累积开销越明显。

使用std::variant能否缓解问题？ #

std::variant可以部分缓解内存占用问题，但无法解决所有根源：

• 减少虚函数开销：用std::variant替代基于EntryBase的继承体系，存储不同类型的可序列化对象，可避免虚函数表和虚函数实现的额外开销。std::variant是编译期多态，无需虚函数机制，所有类型处理逻辑在编译期确定，不会生成冗余的vtable代码。
• 提升模板代码复用性：将序列化逻辑统一到针对std::variant的通用处理函数中，可减少重复的模板实例化。例如，为std::variant实现通用pack方法，而非为每个Entry<T>单独实现，相同类型的序列化逻辑可共享一份实例。
• 局限性：std::variant无法解决模板实例化的根本问题——只要每个字段的序列化逻辑仍由模板驱动，不同类型的字段依然会生成独立代码。此外，std::variant本身需要存储类型索引，对齐要求也可能导致少量空间浪费，但整体比虚函数体系更紧凑。

额外优化建议 #

• 合并基础类型序列化逻辑：将uint32_t、std::array等基础类型的序列化/反序列化实现提取为非模板函数，通过类型擦除（如void*配合类型标识）复用代码，避免模板实例化重复。
• 简化元数据存储：如果不需要字段级哈希校验或版本兼容性，可去掉每个字段的哈希值存储；或改为存储结构体整体的哈希，减少元数据开销。
• 使用编译期反射自动生成代码：利用C++20编译期反射特性（或第三方库）自动生成序列化代码，避免手动编写pack方法带来的模板冗余，同时减少重复代码。
• 优化StorageEntry结构：调整StorageEntry成员顺序，减少对齐产生的内存空洞；避免std::aligned_storage_t的冗余空间，直接存储对象（若类型大小固定）。

内容的提问来源于stack exchange，提问作者klonyyy