在C#中使用Managed API的有效替代方案？

Question

因此,如果我直接使用kernel32删除我的文件作为示例,它是否更有效地替代此C#API？

System.IO.File.Delete(string Path);

如果我像这样导入dll并只使用DeleteFile("C:.."):

[DllImport("kernel32.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool DeleteFile([MarshalAs(UnmanagedType.LPWStr)]string lpFileName);

效率会更好吗,比如执行代码需要的时间？

Answer 1

管理代码很慢是一种相当普遍的误解.通常它不是,你执行C编译器生成的相同类型的代码,机器代码.它与作为操作系统函数包装器的大量.Net框架类特别无关.

像File类一样.事实上,File.Delete()方法会对DeleteFile()winapi函数进行异或.必然如此,这是在Windows上删除文件的唯一方法..NET框架无法做任何事情,至少在托管操作系统可用之前是这样.实际上可能会发生这种情况,微软的超级秘密Midori项目旨在开发这样一个操作系统.

但那是未来的音乐,现在它是C代码的一大块,埋在像Fat32或NTFS这样的文件系统驱动程序中,实际上可以完成工作.它以磁盘速度运行,在文件系统驱动程序确认删除完成之前,DeleteFile()不会返回.这非常非常慢.对于老式硬盘驱动器大约需要50毫秒,而在SSD的亚毫秒级范围内.

File.Delete()确实添加了代码,它执行了大量的错误检查.如果验证您传递的参数不为null,请检查您的代码是否未在拒绝文件删除权限的沙箱中运行,检查您是否未在路径中指定文件路径中不合法的任何字符,将增量路径转换为完整路径并检查它是否仍然是合法路径,检查路径字符串是否不太长,如果需要,将短MS-Dos 8.3名称转换为长名称.

这是一堆工作,但这是以微秒为单位测量的.如果您按下DeleteFile,那么您将跳过该代码,但最多只能使它快〜1%.您将失去的是可靠性,保证如果您的代码或数据中有oops,您将被告知它.有一个非常明确的异常消息,告诉你到底出了什么问题.非常有价值,因为那些几微秒乘以十亿仍然无法与调试不起作用的DeleteFile()所花费的时间和精力相匹配.

不要这样做.