来看看Flash的奇葩数据结构，你就知道为什么Flash慢如蜗牛了

noword2k

狗蛋 发表于 2012-01-18 12:07
Download the SWF file format specification

这是swf的文件格式，又不是运行期数据格式……

我又看不到adobe的源码，我怎么知道啊。

不过估计是直接拿来运算的，否则干吗要设计这种格式呢？
玩大点的flash游戏有一个进度条，那是下载的进度条，而不是在做解包运算。下载完成后是直接解释运行的，基本上没有等候的时间

另外，如果为了缩小体积的话，不是还有zlib吗？信息量是固定的，压缩后能有多大差别。

Android上的flash新版本，号称能把速度提高1000倍云云，可想而知原来的有多慢了。

狗蛋

noword2k 发表于 2012-01-18 13:25
我又看不到adobe的源码，我怎么知道啊。

不过估计是直接拿来运算的，否则干吗要设计这种格式呢？

你用XML是直接拿来运算的吗？

玩大点的flash游戏有一个进度条，那是下载的进度条，而不是在做解包运算。下载完成后是直接解释运行的，基本上没有等候的时间

用过windows的全盘压缩或者压缩目录没有？和直接用硬盘没区别，甚至更快。因为解压缩实在不需要消耗什么CPU。

下载完成后是直接解释运行的，基本上没有等候的时间——这不正说明了分析/载入这种数据并不需要可感知的时间消耗吗？

另外，如果为了缩小体积的话，不是还有zlib吗？信息量是固定的，压缩后能有多大差别。

多一个间隔0就多了1bit信息；多N个间隔0，起码多了ln(N)+1个bit的信息。

Android上的flash新版本，号称能把速度提高1000倍云云，可想而知原来的有多慢了。

这个没看过源码，谁知道他优化哪儿了。

noword2k

狗蛋 发表于 2012-01-18 13:48
你用XML是直接拿来运算的吗？

xml是文本，是一回事吗？
至少我看过的unreal 3，unity3D等游戏引擎，都是把数据直接载入内存的。
载入内存的同时，还要再处理一遍，这不是脱裤子放屁吗？载入原始的数据需要内存，处理数据需要CPU，保存处理的结果还需要内存，当初为什么不直接保存成能直接使用的格式呢？

不知道你是否学过信息论，理解信息量的概念。

等我有空写个程序，比较一下，分别用变长的结构，和定长的结构，保存一组相同的数据，压缩后看看到底有多大差别。说不定还是定长比较小呢。

狗蛋

noword2k 发表于 2012-01-18 17:08
xml是文本，是一回事吗？
至少我看过的unreal 3，unity3D等游戏引擎，都是把数据直接载入内存的。
载入内存的同时，还要再处理一遍，这不是脱裤子放屁吗？载入原始的数据需要内存，处理数据需要CPU，保存处理的结果还需要内存，当初为什么不直接保存成能直接使用的格式呢？

不知道你是否学过信息论，理解信息量的概念。

等我有空写个程序，比较一下，分别用变长的结构，和定长的结构，保存一组相同的数据，压缩后看看到底有多大差别。说不定还是定长比较小呢。

xml是文本，是一回事吗？
——————————————————————————
我以为你不知道呢。
定义是定义，数据是数据，存储是存储，别往一块扯。


至少我看过的unreal 3，unity3D等游戏引擎，都是把数据直接载入内存的。
——————————————————————————
何谓“直接载入内存”？
直接开malloc一块内存，然后直接fopen/fread 然后直接 memcpy再强制类型转换就能用？懂啥叫对象序列化吗？


载入内存的同时，还要再处理一遍，这不是脱裤子放屁吗？载入原始的数据需要内存，处理数据需要CPU，保存处理的结果还需要内存，当初为什么不直接保存成能直接使用的格式呢？
——————————————————————————
同上，何谓能直接使用的格式？

linux 还连内核模块都先压缩一遍呢，有本事载入时它别解压，就那么直接用吧。


不知道你是否学过信息论，理解信息量的概念。
——————————————————————————
你真懂信息论？我看未必。

即使你懂，不好意思，zlib不懂。它就是觉得0000 0111 和 0000 0101 比 0111 0101携带的信息量大。因为它还是必须知道如何还原前两者那5个前导0。

对压缩算法来说，别以为垃圾信息就不是信息。

noword2k

先来说说“直接载入内存”。
对于不压缩的数据，直接开malloc一块内存，然后直接fopen/fread，这块内存就此保留下来了，根据索引信息，直接读取这些数据，没有什么memcpy，没有对象序列化。
而压缩的数据，只是在最前面多一步解压缩而已。

如果flash要在载入时解析的话，就需要malloc一块内存，然后fopen/fread，然后再malloc一块内存（由于是变长的，此时还不知道究竟需要多大的内存，falsh文件里是没有这个数值的，这又多了一个动态内存的管理的开销），将解析出来的新数据，写入到新的内存中。而这样做的好处无法是非常有限的减少了文件的体积，坏处是大大增加了内存和CPU的损耗。

而问题时，减少文件的体积，是压缩算法的工作，根本不应该在数据结构层面上去考虑。
如果这种减少文件体积的方法非常有效的话，flash也不需要在版本 6 以后，推出支持 zlib 压缩的版本了。

-------------------------------------------------

关于信息量的问题。
如果信息量相同，不管你使用什么样的数据结构，用一个给力的压缩算法压缩后，彼此间的大小会非常接近。

为此，我写了个程序来验证一下。（见附件，用python编写，需要到googlecode下载一个bitstring模块）
flash中有一个变长的Rectangle record，保存4个值。这是需要使用的第一种数据结构。
第二种结构，用int32来保存这4个值。
第三种结构，用int64来保存这4个值。

生成随机数，往这3种结构里写入相同的数值，各10000组，然后分别用普通的zlib，和最高强度的zlib压缩这些数据。
结果如下：

	原始数据	比率	zlib普通压缩	比率	zlib level9压缩	比率
rect	59954	1	55862	1	55862	1
int32	160000	2.6687126797	66966	1.198775554	60056	1.0750778705
int64	320000	5.3374253594	73019	1.3071318607	66414	1.1888940604

可以看到，虽然原始的数据相差很大，但是由于信息量相同，压缩后他们的大小差的并不大，并且随着压缩等级的提高，这种差别会越来越小。

zlib是一种比较古老的压缩算法，将原始数据保存出来后，我用7zip(lzma算法)压缩了一下，大小如下。
55,892 rect.7z
49,593 int32.7z
49,700 int64.7z
验证了我前面说的，“说不定还是定长比较小呢”。

test_strcut.zip (978 Bytes, 下载次数: 14)

2012-01-18 21:00 上传

点击文件名下载附件

noword2k

昨天的程序，在取值范围上有问题，但是最终结果是一样的。
今天再补一个。

三月廿七

狗蛋 发表于 2012-01-18 12:16
从文件格式的角度上说，最该骂的反而是没有任何“奇葩数据结构”的XML。

奶奶的至少30%的空间都用来存ta ...

json 只支持数组, 不支持 tree
   

三月廿七

xml 的数据结构不是很伟大， 但是json比不了，
xml 不过是一棵树的文本表示，不用tag也可以表示的