关于神奇的wimboot技术为什么不会降低性能的一个大神的阐述

sairen139

关于神奇的wimboot技术为什么不会降低性能的一个大神的阐述

WIMBOOT是Windows8.1 Update新引进的特性。它让你的系统盘的大部分系统文件都指向一个经过特别处理的WIM文件。当系统要读取相关文件时，会直接从WIM文件读取。

Wimboot

• 中文名
  映像文件启动
• 外文名
  WIMBoot(Windows image file boot)
• 支持的系统
  Windows 8.1 Update及以上
  

术语解释WIMBoot是Windows image file boot的简称，其工作原理就是通过系统直接读取某个WIM映像完成整个启动过程，也就是WIM映像等同现有的系统盘，而且其体积大幅压缩。

最近一个月老在研究微软的wimboot技术，目前已知从各种网友的实验中比起正常系统来，得知vhd会降低性能，而微软神奇的wimboot技术却不会降低性能反而会提升速度。

下面是一个ramos群里的大神对wimboot这种神奇技术不会造成性能下降的原因的推断，大家可以验证辨析一下。

下面的阐述来自Ramos群的群友@monitor20:

能确定的一点是，wimboot是不需要挂载的，而是通过特定的驱动直接把访问转移到了wim文件本身，根据偏移量得到文件的访问地址。

如果wimboot的wim是在内存，就是内存的速度，如果读取的是硬盘的，就是硬盘的速度。即wimboot.wim所在介质本身决定了性能速度。

程序执行的时候，只有代码到了CPU那会儿才是一致的。程序访问，甚至推广到任何数据访问，本身都是部分读取的，而不需要先有一个完整的文件。对于CPU而言，送来啥指令，就执行啥功能，不会关心是硬盘读的，还是网络上的，硬盘上的程序只是持久化的代码合集，中间是从wim读取的，还是网络传输的，还是ntfs压缩的，这些对cpu而言是无差别的。就算硬盘直接读取的文件，也得是windows送过来的，部分解压，而不是全部解压后执行，那么对速度就没什么影响。

目前结论：wimboot不是挂载wim包里的文件出来。而且monitor20大神亲自在电脑上做了对比实验，实验发现wimboot系统的线程数和普通正常硬盘系统的线程数是几乎一致的。

现在可以找到wimboot技术是从wim包里读取数据的证据了，据ramos群友@黑中见白 提供的一款名叫龙腾缓存的工具，可以看出p驱内存盘上wimboot.wim里系统读取数据的大小。

终极原理解释：通过哈夫曼算法（一种不牺牲性能，却明显减少体积是压缩算法）的wimboot技术可以在不牺牲性能的前提下实现用占用体积更小的wimboot.wim包来取得和正常硬盘系统一样的效能！通过wimboot压缩技术以wim文件的形式存在并被读取，这是一种特殊的文件索引方式，而其他普通的文件的索引方式可以称之为指针索引方式，这是两种不一样的文件索引方式。被“wimboot.wim化”的文件，读取的时候不存在“解压缩”的过程，这种文件压缩方式跟文件被压缩成rar跟zip之类的是不一样的。因此在文件读取效率上不存在中间过程，因此可以放心地使用这一技术进行压缩。wimboot.wim包里的文件的使用是以指针分区映射到wim包里的方式运行，windows运行过程中没有解压的中间过程，而是直接读取使用wim包里的文件！

PS：关于哈夫曼编码压缩概念的基本思想?

哈夫曼编码(Huffman Coding)是一种编码方式，哈夫曼编码是可变字长编码(VLC)的一种。 Huffman于1952年提出一种编码方法，该方法完全依据字符出现概率来构造异字头的平均长 度最短的码字，有时称之为最佳编码，一般就叫作Huffman编码。 以哈夫曼树─即最优二叉树，带权路径长度最小的二叉树，经常应用于数据压缩。 在计算机信息处理中，“哈夫曼编码”是一种一致性编码法（又称"熵编码法"），用于数据的无损耗压缩。这一术语是指使用一张特殊的编码表将源字符（例如某文件中的一个符号）进行编码。这张编码表的特殊之处在于，它是根据每一个源字符出现的估算概率而建立起来的（出现概率高的字符使用较短的编码，反之出现概率低的则使用较长的编码，这便使编码之后的字符串的平均期望长度降低，从而达到无损压缩数据的目的）。这种方法是由David.A.Huffman发展起来的。 例如，在英文中，e的出现概率很高，而z的出现概率则最低。当利用哈夫曼编码对一篇英文进行压缩时，e极有可能用一个位(bit)来表示，而z则可能花去25个位（不是26）。用普通的表示方法时，每个英文字母均占用一个字节（byte），即8个位。二者相比，e使用了一般编码的1/8的长度，z则使用了3倍多。倘若我们能实现对于英文中各个字母出现概率的较准确的估算，就可以大幅度提高无损压缩的比例。


如果内存小而且硬盘上的系统分区要腾空间出来可用wimboot这个返璞归真的方法如下图dism++释放时☑️勾选wimboot项即可：

liujun2000

很好

邪恶海盗

我只知道PE里用的时候有个解压的过程...

9695

学习

kkkssc

primo ramdisk + wimboot  Ramos 无敌

黑中见白

问题来了，WimBootCompress.ini
的内容是啥WimBootCompress.ini
不经过改动，
wim包塞ramdisk上是没法启动的

lbw2007

说句题外话，对以下内容有争议：

最近一个月老在研究微软的wimboot技术，目前已知从各种网友的实验中比起正常系统来，得知vhd会降低性能，而微软神奇的wimboot技术却不会降低性能反而会提升速度。

之前有坛友分享过测试结果：[转贴] 传统、VHD、VHDX性能对比测试（转帖）结论是不同模式基本没有区别。我自己也在用VHD，没发现与传统模式性能上的差距。请问楼主所说的VHD会降低性能这一说法，从何而来？

teamviewer

学习了解一下。原来如此。

xman00

能不能不要拿到一半就开跑

ls68057121

！！！继续呀

283598328

这不是文字游戏吗？什么程序和构造执行从微观看不是从特征码开始执行的？就是你用眼睛看人也是从微处着手啊。换了了描述方法就云里雾里的高大上了。这位“大神”只是抓住了语言的“精髓”忽悠了一番而已。就像把耳熟能详的事情用不可描述的方式忽悠了三岁小孩。

x9tian

谁告诉你WIMBoot 不卡的,  
你压缩率压到最狠:
   用分离增量: --delta  WIM  (官方WIM) 和 append   dwm (wimlib-imagex 的最大压缩比)

  不同的压缩比, 开机进游戏,随你多好的配置,就没有开始不卡的.  卡一分儿就好了.
  

junyee

vhd 确实有性能损失,在HDD上比较明显.

wimboot 一直没敢用,其实也不如vhd方便.
压缩对CPU性能肯定有损失的,
哪怕是硬件解压缩也不如IO直读.

xman00

暖贴一把

qq2348227

学习一下~凹力給…

bfgxp

对于想在pe环境看着分区内容简洁的，wimboot+vhd是最优解
至于性能，感觉不明显。
关于性能还有一个特例，同一台计算机，基于vboot1.1驱动的vhdXP的读写性能明显高于常规硬盘安装的XP系统。

CodeHz

这文章虽然结论对的，但是具体解释我觉得解释歪了
所谓指针文件就是一个ntfs reparse point（NTFS重解析点），具体知识需要看windows internal
不能说它不是挂载，你可以把它看作一种特殊的文件系统标记，可以给文件系统过滤器驱动提供信息，然后wimboot实际使用的就是WoF.sys(windows overlay filesystem)，它的作用类似于linux上的unionfs/overlayfs，就是可以把多个目录结构折叠到一个目录里，wimboot里就是把wim表示的文件作为最底层，然后写入时则会进入另一层，这个过程和ntfs mount point的实现几乎没有区别，ntfs的挂载点也是创建一个reparse point（对整个目录，而不是按文件），然后由过滤器驱动去处理这个目录下的读写请求，区别就是有没有合并多个层。
（在现代windows上重解析点使用很广，one drive的按需下载的文件也是通过reparse point实现的）
再说说解压，解压缩再快还是有区别的，这里看不出的主要原因是相比于ssd的访问延迟和吞吐量来说，LZMS/LZX的解压缩根本不在一个数量级，然后由于不需要考虑后期写入的问题，所以文件的块可以直接顺序排列（这点上甚至优于传统文件系统，但是由于wim文件本身也在别的文件系统里，所以还是会被分块和重新排列，所以优势有限）。
从这个角度来说，wim和普通的压缩没有特别大的区别，几个区别就是它能正确保留ntfs的各种信息，包括权限和额外数据流，以及更为紧凑的数据组织形式，之所以觉得解压普通压缩文件慢（不考虑开高压缩的），主要因素是需要先完整解压完整文件才能开始使用，用户体验上差了很多，理论上可以微软是可以把zip变成WoF这样的实现的，但是估计微软是不打算改了。
这类技术甚至可以在移动设备上使用，某为的EROFS也是基于这个原理对系统分区做压缩，同时不影响读取性能。
vhd(x)之所以影响大，是因为它的格式要允许写入，所以不能直接按顺序排列文件的块，然后文件本身又被上层文件系统再次分块，等于访问一个文件要经过两个不同层次的间接索引，性能自然影响不少，但是好处是可以无缝写入新文件，和修改文件wim要修改基本等于重建，如果是正常系统，更新的时候就会gg，所以现在微软主推compact，虽然压缩率低了点，但是可以方便的修改和替换文件

xman00

CodeHz 发表于 2020-12-8 20:02
这文章虽然结论对的，但是具体解释我觉得解释歪了
所谓指针文件就是一个ntfs reparse point（NTFS重解析点 ...

请问：
”所以文件的块可以直接顺序排列（这点上甚至优于传统文件系统，但是由于wim文件本身也在别的文件系统里， 所以还是会被分块和重新排列“
应如何理解呢？

CodeHz

xman00 发表于 2020-12-11 17:43
请问：
”所以文件的块可以直接顺序排列（这点上甚至优于传统文件系统，但是由于wim文件本身也在别的文 ...

1. 正常的文件系统都会对文件进行切割和重新排列以提升空间利用效率，所以文件只要超过一定大小就几乎一定会被重组（太小的甚至可以直接压到元数据里，不会被切割）
2. 压缩文件内部可以把文件按顺序直接排列，但是作为文件，它本身仍然表现为普通文件，会被文件系统所分块
3. 但是也不是完全没有好处，毕竟如果是多个独立的不同文件，（你看vmware的虚拟磁盘就有这个选项），则更有可能产生更多的分块。
4. 文件分块这一事实不能在一般软件中察觉出（即使是WoF驱动），因为已经在ntfs那一层被包装了
5. 文件分块未必会真的降低性能，考虑到现在磁盘技术的发展，这部分损耗可能没有显著的性能影响——除非剩余可用空间过小，随便放点文件就一堆碎片（

xman00

CodeHz 发表于 2020-12-11 18:04
1. 正常的文件系统都会对文件进行切割和重新排列以提升空间利用效率，所以文件只要超过一定大小就几乎一 ...

那请教楼上你对wimboot对系统性能的影响是如何的看法呢？越细腻越好

12250279

求大神来一个，一键WIMBOOT 一键释放指针的 BAT程序