像为了做nView插件和Susie插件的导出函数，这些函数我们都用不上，真正能用得上的只有一两个。
相信那些导出函数也是占了一些体积的。ucidec.dll占1.85M，倘若清除掉那些插件函数，只编译UCIDecode和UCIFree，不知道能否有希望控制在1M以内。
过多的导出函数不但会影响DLL体积，也会略微影响DLL调用的效率，因为DLL调用时会遍历整个导出表，找到函数名对应的地址。
总觉得把这些函数一起放在ucidec.dll不是一个明智的决定。dwing，能否推出一个精简版呢？


其实绝大部分体积都是UCIDecode这个函数, 其它函数估计只占0.1MB
体积比较大的原因:
1.gcc优化编译,大量内联和循环展开
2.很多的各型号CPU的汇编优化
3.H.264解码的完整支持, 支持很多次要特性, 甚至UCI肯定不会用到的, 但这部分很难分离掉.

至于效率, 遍历导出表只是加载DLL第一次初始化时, 只要程序进入运转状态, 效率不会降低, 和体积关系不大.

我不知道你要用在什么地方, 大部分情况应该不会在意ucidec.dll的不到2M的体积, 而且这个文件可以被压缩到400KB以内.
对于体积大于100M的游戏来说, 这点体积应该没什么影响.
效率上, 对于多数游戏来说, ucidec的解码速度已经足够快了, 对于大型游戏来说, 建议用后台线程解码, 毕竟多核CPU已经普及了.

LZ这是打算用在哪呢? 居然连导出表对体积和加载效率的影响也要考虑进去了?
"因为DLL调用时会遍历整个导出表，找到函数名对应的地址。"
这个只有在GetProcAddress这类的用法上会遍历吧?

算是游戏领域吧。写了一款很烂很烂很烂的游戏引擎（基于OPENGL，因为UCI能直接解码出RGB和RGBA数据流，很契合OPENGL，所以很关注UCI），现在引擎最大的特色就是，没有任何DLL，空白主程序（就是纯OPENGL窗口）只有40K，现在引擎最大的缺陷就是，只能加载RGB或RGBA数据流，不支持其它任何格式的任何压缩，于是游戏素材的体积就显得比较庞大。
不忍心破坏那么小体积的引擎的纯洁性，可是又无法割舍UCI的高压缩效率。

不知道你是用什么方法把它压缩到400KB以内的呢？求教。试了一下，不加壳纯压缩，ZIP格式401K，7Z格式402K，RAR格式405K，还是到不了400K以内。配壳的话，压缩率反而更低，UPX451K，PEC402K（+ZIP400K）。试了很多方法，只能很接近400K，还是到不了400K以内。

让d大用VC编译一个版本, 应该在400KB以下

0.5版的ucidec.dll用7z可以压缩到395K, 注意选"极限压缩","LZMA"
加壳再用7z压肯定更低
以后的版本不再打算用VC编译.

RGB或RGBA数据流是很通用的, GDI,DX,OPENGL以及很多其它的图像接口基本都用这种数据流.

gcc可以用fprofile大幅度减小体积

用fprofile编译测试了一下, 体积可以从 1.85M 减到 1.16M, 效率未测试
压缩后的体积从 395K 减到 315K

求fprofile编译版。

fprofile版的ucidec.dll:
u。115。com/file/dn6tznsr
请自行测试对比