C语言文件管理器的高效链表设计优化问询

我用C语言开发一款基于ncurses的文件管理器，采用单链表存储当前工作目录的文件列表，节点结构体定义如下：

typedef struct FileNode {
    char name[256];
    struct FileNode* next;
} FileNode;

目标运行在UNIX系统（ext2/3/4、BTRFS等），已知文件名长度不会超过255字符加终止符。需求包括：

• 文件重命名时仅修改节点名称而非重建链表
• 链表需按文件名排序，重命名后节点可能需要调整位置
• 后续可能为结构体添加用户选中状态等成员

当前遇到的问题：

• 结构体预留256字节存储文件名，大量短文件名场景下内存浪费严重
• 采用动态分配文件名会导致创建大文件列表或批量重命名时开销显著增加

我曾考虑使用柔性数组方案：

typedef struct FileNode {
    struct FileNode* next;
    char name[]; // 必须是最后一个成员
} FileNode;

但发现重命名操作需要释放旧节点并创建新节点，实现复杂；而且初始创建时需要遍历所有文件名长度来适配结构体，成本较高。想请教该如何处理？

方案一：混合存储（短文件名栈分配，长文件名堆分配） #

定义结构体时内置小缓冲区覆盖多数短文件名场景，同时用指针处理长文件名，搭配标记区分存储方式：

typedef struct FileNode {
    struct FileNode* next;
    int is_allocated; // 0=用内置缓冲区，1=用堆分配指针
    union {
        char short_name[32]; // 可根据实际场景调整大小
        char* long_name;
    } name;
    int selected; // 预留的选中状态成员示例
} FileNode;

• 核心逻辑：
  1. 创建节点：判断文件名长度，小于32字节就存在short_name，否则malloc内存存到long_name，同步更新is_allocated标记
  2. 重命名：先检查新文件名长度，若适配当前存储方式直接覆盖；若需要切换，释放原有堆内存（如果存在）后重新分配对应空间存储新名
  3. 销毁节点：根据is_allocated标记决定是否释放long_name的堆内存
• 优势：兼顾短文件名的低开销和长文件名的内存效率，重命名无需重建节点，仅按需调整存储

方案二：固定缓冲区+内存池优化 #

继续使用固定大小的文件名缓冲区，通过内存池优化分配/销毁性能：

typedef struct FileNode {
    struct FileNode* next;
    char name[256];
    int selected; // 预留成员示例
} FileNode;

• 核心逻辑：
  1. 初始化时申请一块连续内存，按sizeof(FileNode)分割为多个节点，用链表管理空闲节点
  2. 创建节点从内存池取空闲节点，销毁时放回内存池
• 优势：
  • 批量创建/销毁节点的开销远低于零散malloc/free，解决大文件列表的性能问题
  • 连续内存分配提升缓存命中率，遍历链表速度更快
  • 重命名操作直接修改name数组即可，完全不涉及节点重建
• 补充：可根据实际场景调整缓冲区大小，比如若多数文件名在64字节以内，可改为char name[64]，内存池的连续分配也能缓解碎片问题

方案三：柔性数组+冗余空间优化 #

若坚持用柔性数组，通过预留冗余空间降低重命名时的节点重建频率：

typedef struct FileNode {
    struct FileNode* next;
    int selected; // 预留成员示例
    char name[]; // 必须是最后一个成员
} FileNode;

• 核心逻辑：
  1. 创建节点时，分配内存为sizeof(FileNode) + strlen(name) + 1 + 32（多留32字节冗余空间）
  2. 重命名时，若新文件名长度不超过节点总内存大小，直接覆盖修改；若超过则销毁旧节点创建新节点
• 优势：内存利用率最高，多数重命名场景无需重建节点；缺点是实现复杂度略高于前两个方案

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