[再次升级!没有最好,只有更好!] 昨天是UPS,今天是复印机... -_-b (内含独特促销附送程

以下引用03534在2006-1-22 11:39:18的发言： 窗口大小随能随意调节大小， 但不能记忆，每次打开程序的时候还是要调节………… - -b 不可能每次都要调一下大小吧……

要跨进程保存数据就需要操作注册表或者使用ini文件...我的目标是纯绿色软件，因此不会加入这个功能...

不过有一个办法可以比较快速的调到不错的大小，那就"最大化"按钮... ^o^

另外建议能加上目标磁盘空间剩余大小…… 免得总是先要看看硬盘空间剩余大小，再跑去启动程序……（方便硬盘空间经常爆满的人……这里貌似有不少吧……） （某比较白……建议都是从程序的友好、方便上面考虑的…………）

这个建议不错，接下来就加入！

以下引用scegg在2006-1-22 12:26:45的发言： 如果要复制大量的数据，建议看看目前最新的几个技术点（来自多家公司产品和研究机构）： 1 使用底层方式，直接控制硬盘驱动层甚至直接控制硬盘动作（部分系统不允许，而且需要对不同硬盘规格分别编写代码） 2 使用Smart I/O技术（Diskeeper），激活该技术以后，操作硬盘将不会影响用户其它操作，当软件检测到用户需要对硬盘读写的时候，将自动暂停，并在空闲时恢复。比如Diskkeeper可以同时打开多个磁盘的整理，而系统不会全部都动作。 3 使用可选择的整合技术，即可以独立执行，又可以嵌入到系统中。 4 使用NTFS散列文件方式，或者使用快速预分配硬盘空间的API，避免复制文件产生的碎片。 如果谈什么线程优先级、大缓存什么的，建议看看上个世纪就有个一个TotalCopy，那个软件在98下就有了，而且也支持断点再COPY，支持关机恢复什么的。 引用大史记的话……“咋怎旧的，整点新的”

赫赫，可惜的是，这些技术都用在高性能的集成环境里面，比如Web服务器，数据库，硬盘整理......

像Copy一个文件，而且还是在同一个物理磁盘，而且还是万转以下的，而且还不支持NCQ的......干这种事情的都是像我一样的穷光蛋罢了...

况且在这样弱的一个硬件环境下:
用256MB缓存来帮助整理硬盘磁头的操作提升25%的性能
用上面的天花烂醉的技术估计也就提高30%的性能

...谁会花如此大的精力把如此高技术含量的东西用在一个如此弱的硬件上来获得每周节约大约几十秒钟的时间的效果?

哦，对了，楼上还有一个误解，就是复制文件就一定会产生碎片。

其实，在一般的情况下，复制文件是不会产生碎片的，因为我们这些穷人一般都是一次复制一个文件，不会同时进行其他的写操作——普通的万转以下、不支持NCQ的IDE硬盘，要达到理想的速度只能一次干一件事情，如果一个硬盘的操作序列里面同时有两个任务或更多，磁头就会来回交错的执行，导致效率程指数式下降...

我的程序解决的仅仅是一个非常特殊的情况，那就是，在同一个物理硬盘上复制一个文件(仅有这一个操作)。尽管高级操作只有一个，但是对于底层硬件来说，操作序列里面就同时有两个任务，一个读一个写。

这样整个过程的时间就不仅仅是读和写的时间，而是 读+写+(寻道*N) 而Windows提供的复制过程，这个N非常的大，因此速度非常的慢，我的程序的目的就是，减少这个N的值，使整个操作速度接近于硬盘本身的读写速度。

(所以说，和楼上说的什么碎片不碎片完全不沾边)



再说极限速度吧...

打个比方，复制一个 800MB 的文件，硬盘读需要30秒，写需要25秒，寻道一次需要10ms
如果用Windows，估计整个过程需要来回切换上百次，就算800次吧:

30s读 + 25s写 + (10ms * 800 * 2)
= 55s + 16s = 71s

如果使用256MB的缓存，整个过程需要切换4次:

30s读 + 25s写 + (10ms * 4 * 2)
= 55s + 80ms =(约等于) 55s

就算其他的这个技术那个技术再强，硬盘的纯读写时间是改变不了的，最多也就是把那个 80ms 变成 20ms ....

(再次说明: 因为整个过程中没有在同一个磁盘进行其他的写操作，因此不涉及产生碎片问题)

以下引用scegg在2006-1-22 14:10:21的发言： 41楼正解。 Server家族的系统均支持打开大缓存支持。所有的复制操作都会使用所有可用的内存进行缓存。缺点就是复制大文件的时候搞不好就会可用内存不够。

其实并不是Server独有的功能，XP和2003里面系统属性里面内存分配策略都可以选择使用更多内存优先作为缓存...

但是...Windows在内存管理方面有的时候的确是非常的愚蠢...我都不好说了....当选择使用更多内存优先作为缓存时，在连续复制大量的大文件(>1G)时会可能产生连锁恶性反应...

1. Windows尽量的把物理内存分配给文件系统，当现有的空闲内存分配完后，就会开始将后台程序以及部分的核心内存转移到交换文件上(也有可能那些内存本来是干净的，也就顺便被Windows利用了)

2. 这个时候，有一些程序开始请求一些交换出去的页，但是内存已经被占用满，然后Windows就把部分占用的内存页写出到交换文件，然后把需要的页读回来

* 问题出现了，愚蠢的Windows居然不知道在这种情况下减少分配给文件系统的缓存，以减少再次发生页面错误....而且更加过分的是，有的时候它居然把分配给文件系统的缓存也"交换"到了交换文件上！

* 让我们来看看这种情况下的硬盘操作:
  文件复制
  1. 文件读取
  2. 交换文件写 (老的缓存页交换出)
  3. 交换文件读 (出现页面错误的缓存页交换入)
  4. 文件写
  其他进程
  1. 交换文件写 (老的缓存页交换出)
  2. 交换文件读 (出现页面错误的缓存页交换入)

一个小小的IDE硬盘操作队列里面居然有6个任务.....这个时候硬盘已经开始狂响，而每个任务的执行速度估计也就下降到几百K每秒....因为部分内核被交换出，因此，用不了多长时间，有几页的核心内存出现页面错误，于是再雪上加霜...因为核心部分的代码多涉及中断，因此系统中断队列阻塞——出现这种情况就比较的明显了，因为你的鼠标已经开始反应不灵活，最后干脆就停下来不动了....

于是整个系统就处于典型的连锁恶性反应(Thrashing)中，少则几十秒，多则几分钟，这段时间对键盘、鼠标、网络等等的输入均无反应.....等到系统恢复反应时，一般来说所有的TCP连接早就超时中断了....


这是典型的因为内存管理不善造成的后果，在256MB内存下反应最强烈(像当年刻录机保护技术还不成熟，因此烧飞了无数的DVD-R)，1G内存下也不少见，包括HyperThreaded的CPU...

Server2003用了2年，XP前后用了3年，烂起来都差不多 -_-||

以下引用LOVEHINA-AVC在2006-1-24 20:49:20的发言： 不可以.NonPagedPool的内存只能占总物理内存的15%左右.在WINDOWS内核中,大内存的申请通常都是PagedPool的.你可以不使用虚拟内存,但分页的性质不会改变(即使它从来不会被换页到硬盘上)

但是，Windows至少可以把分配给文件系统的缓存页面锁定一下嘛...将磁盘缓存交换到磁盘上是100%不合算的行为，为什么他们连这点都想不清楚... -_-|||

哦，对了，很早就发现，在Windows系统安全策略里面，内存中锁定页这个操作允许的Group居然是空的...难道这个功能一直没有被使用？(或者是RING0级别的程序不受策略限制？)