我在这里找到了这篇文章:
量化垃圾收集与显式内存管理的性能
http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
在结论部分,它写道:
通过比较一系列基准测试的运行时,空间消耗和虚拟内存占用,我们表明,当给定足够的内存时,性能最佳的垃圾收集器的运行时性能与显式内存管理相比具有竞争力. 特别是,当垃圾收集的内存是所需内存的五倍时,其运行时性能与显式内存管理的性能相匹配或稍微超过.但是,当必须使用较小的堆时,垃圾收集的性能会大幅降低.内存的三倍,平均运行速度慢17%,内存增加一倍,运行速度减慢70%.当物理内存不足时,垃圾收集也更容易被分页.在这种情况下,我们在这里检查的所有垃圾收集器都会受到相对于显式内存管理的数量级性能损失.
所以,如果我的理解是正确的:如果我有一个用本机C++编写的应用程序需要100 MB内存,要实现与"托管"(即基于垃圾收集器)语言(例如Java,C#)相同的性能,应用程序应该要求5*100 MB = 500 MB？(并且2*100 MB = 200 MB,托管应用程序比本机应用程序运行速度慢70%？)
您是否知道当前(即最新的Java VM和.NET 4.0)垃圾收集器是否遇到上述文章中描述的相同问题？现代垃圾收集器的性能有所改善吗？
谢谢.
使用Spy ++工具,似乎有些Microsoft应用程序使用NetUIHWND和DirectUIHWND窗口类; 例如:Word 2010的功能区似乎是一个NetUIHWND,而Windows Live Messenger窗口似乎是一个DirectUIHWND.
这些窗口类似乎有一些很酷的图形(有阴影,渐变等); 是否可以在我们自己的Win32 C++应用程序中使用这些窗口类？有没有关于它们的文件？
我对编程非常适合嵌入式编程的语言很感兴趣.特别是:
是否可以用C++编写嵌入式系统？或者使用纯C更好？或者,只有当语言的某些功能(例如RTTI,例外和模板)被排除在外时,C++才行吗？
那个域里的Java怎么样？
谢谢.
我需要按顺序读取(扫描)文件并处理其内容.文件大小可以是从非常小(某些KB)到非常大(某些GB)的任何内容.
我尝试在Windows 7 64位上使用VC10/VS2010的两种技术:
我认为内存映射文件技术可能比CRT函数更快,但是一些测试显示两种情况下的速度几乎相同.
以下C++语句用于MMF:
HANDLE hFile = CreateFile(
filename,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_FLAG_SEQUENTIAL_SCAN,
NULL
);
HANDLE hFileMapping = CreateFileMapping(
hFile,
NULL,
PAGE_READONLY,
0,
0,
NULL
);
按顺序读取文件,按块查看; 每个块SYSTEM_INFO.dwAllocationGranularity的大小.
考虑到MMF和CRT的速度几乎相同,我使用CRT功能,因为它们更简单,更多平台.但我很好奇:我是否正确使用MMF技术？在这种情况下,扫描文件的MMF性能顺序与CRT相同,这是正常的吗？
谢谢.
在编写Win32 C++代码时,我会欣赏一些关于如何处理Win32 API错误的提示.
特别是,如果Win32函数调用失败(例如MapViewOfFile),最好是:
定义从std :: exception派生的Win32Exception类,添加了HRESULT数据成员来存储与GetLastError返回的值对应的HRESULT ？
在后一种情况下,我可以使用what()方法返回详细的错误字符串(例如" 在MyClass :: DoSomething()方法中调用MapViewOfFile失败. ").
1比2的优缺点是什么？
我还缺少其他更好的选择吗？
作为旁注,如果我想本地化我正在开发的组件,我怎么能本地化异常what()字符串？我正在考虑构建一个表,将what()返回的原始英文字符串映射到Unicode本地化的错误字符串中.有谁能建议更好的方法？
非常感谢您的见解和建议.