GF使用Records生成大体积编译文件的优化方案咨询

问题1：不使用抽象层依赖类型的多范畴值整合方案 #

• 构造函数参数平铺：将原本需要打包进Record的所有属性，直接作为抽象语法构造函数的入参传递。比如原本MySentence : Human -> Sentence可以改造为MySentence : Str -> Det -> N -> Numeral -> V -> ... -> Sentence，无需额外的Record容器承载不同范畴的值，编译时也不会一次性加载所有关联范畴的全量预计算内容。
• 自定义轻量存储类型：不直接使用GF标准库的N/V/Det等完整范畴类型，而是根据自身需要的屈折字段自定义极简类型，比如仅需要名词的单数主格形式和词性，就定义为oper MyN : Type = {s: Str; g: Gender}，仅保留必要字段，避免冗余的屈折变体预计算。
• 独立常量组管理：如果属性值为固定常量（比如示例中Joan的姓名、年龄等固定属性），可以拆分为多个独立的oper常量，比如oper Joan_name : Str = "Joan"; oper Joan_job : MyN = mkMyN "Doctor"，需要使用哪个属性直接调用对应常量即可，无需打包为整体Record。

问题2：按需使用属性场景下的性能优化方案 #

• 惰性计算改造：将Record的字段定义为无参数函数类型实现惰性求值，比如原本job : N改造为job : Unit -> N，只有实际调用该字段时才会计算对应屈折形式，未使用的字段不会触发预计算，大幅减少编译时的计算量和gfo文件存储的冗余数据。
• 功能模块拆分：将不同场景的生成逻辑拆分为独立的具体语法模块，每个模块仅依赖当前场景需要用到的属性，避免所有属性都耦合在同一个具体语法文件中，减少单次编译需要加载的资源量。
• 裁剪标准库类型冗余字段：标准库的N/V等范畴默认预计算了所有时态、格、数的屈折变体，90%以上的变体在大部分场景下都不会用到，你可以根据自己的生成需求自定义精简的范畴类型，只保留实际会用到的屈折字段，gfo体积最高可以减少90%以上。
• 开启编译优化选项：在GF文件的flags块中添加optimize = all; unlexer = off;，前者会自动裁剪未使用的代码和数据，后者会关闭gfo中存储的反向解析映射数据，如果只需要生成文本不需要解析功能，这个选项可以让gfo体积缩小50%以上。

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