此外，因为 .NET 4.5 是 .NET 4 的更新，所以即使是 .NET 4 应用程序也可从许多对现有 .NET 4 功能的性能改进中获益。
在本文中，我将简要概述我们在 .NET Framework 4.5 中所做的一些主要性能改进。
CLR
以下是一些主要的性能改进功能。
特别是，自从多核芯片推出后，我们在自己的性能实验室中使用了多核芯片，并且我们已做出适当的更改以利用这一特别的硬件更改；但是，最初这些更改只会为极少数客户带来益处。
作为该调查的一部分，我们发现数量足够多的托管应用程序具有阈值数最小的 JIT 编译方法，这使投资变得值得。
生成配置文件数据这一要求是您与此功能进行交互的主要方式。
请注意，默认情况下对 ASP.NET 4.5 应用程序和 Silverlight 5 应用程序启用此功能。
在我们自己的测试和体验中，我们通常会看到 MPGO 为较大托管应用程序（例如，大型交互式 GUI 应用程序）带来的益处，并且我们强烈建议按这些方式使用此工具。
图 1 显示了相关流程。
图 1 使用 MPGO 工具的进程流
在回收 LOH 上的对象后，这些对象会在未被回收的对象之间留下一些可用空间，这将导致碎片问题。
这会导致应用程序变得无法响应，并最终导致内存不足异常。
请注意，这不会更改 LOH 对象 85,000 字节的限制。
它可最大程度地减少长时间处于阻止状态的回收，同时继续保持高的应用程序吞吐量。
客户端和服务器 GC 的高级后台 GC 的特征是相同的：
- 只有完整 GC（第 2 代）可在后台发生。
- 后台 GC 不进行压缩。
- 服务器 GC 在专用服务器 GC 线程上完成。
- 完全阻止 GC 同样在专用服务器 GC 线程上发生。
异步编程
.NET 4.5 还进行了更新以支持使用这些新关键字的异步应用程序。
msdn.microsoft.com/vstudio/async) 是获取关于新语言功能和支持的示例、白皮书及讨论内容的绝佳资源。
并行计算库
已在 .NET 4.5 中对并行计算库 (PCL) 做出许多改进以增强现有 API 功能。
特别是，与创建任务和安排后续任务相关的案例的性能提高了多达 60%。
这些决策是有根据的猜测且不总是完美无缺，在 .NET 4.5 中，PLINQ 将识别更多类型的可成功并行执行的查询。
更快的并发回收：对 System.Collections.Concurrent.ConcurrentDictionary<TKey, TValue> 做出了许多调整，以使其在特定方案中更快速地执行。
blogs.msdn.com/b/pfxteam。
ADO.NET
这将极大地帮助依据表格格式数据流 (TDS) 协议来对包含众多空列的数据进行压缩。
Entity Framework
自动编译 LINQ 查询：如今在您编写 LINQ to Entities 查询时，Entity Framework 会遍历 C#/Visual Basic 编译器生成的表达式树并将其转换（或编译）为 SQL，如图 2 所示。
Figure 2 转换为 SQL 的 LINQ to Entities 查询
在早期版本的 Entity Framework 中，如果您希望避免每次执行 LINQ 查询时必须为此性能损失承担相应开销，则必须使用 CompiledQuery 类。
bit.ly/iCaM2b 中查阅更多相关内容。
Windows Communication Foundation 和 Windows Workflow Foundation
Windows Communication Foundation (WCF) 和 Windows Workflow Foundation (WF) 团队已完成此版本中的大量性能改进，例如：
- 此问题在 .NET 4.5 中已得到解决。
- 对 WCF HTTP/TCP 的内置 GZip 压缩支持： 使用这一新型压缩功能，我们有望获得高达 5 倍的压缩比。
- 在内存使用量较高时，回收 WCF 宿主： 当内存使用量较高时（可配置旋钮），我们使用最近很少使用的 (LRU) 逻辑回收 WCF 服务。
- 对 WCF 的 HTTP 异步流支持： 我们在 .NET 4.5 中实现了此功能且获得了与异步流相同的吞吐量，但可伸缩性得到了增强。
- 对 WCF TCP 进行了第 0 代碎片改进。
- 针对大型对象优化了 WCF 的 BufferManager： 对于大型对象，已实现更好的缓冲池以避免产生更高的第 2 代 GC 成本。
- 使用表达式缓存改进了 WF 验证： 对于加载并执行 WF 的核心方案，我们有望获得高达 3 倍的改进。
- 已实现 WCF/WF 端到端 Windows 事件跟踪 (ETW)： 虽然这并非性能改进功能，但它可帮助客户进行性能调查。
bit.ly/n5VCtU）中找到更多详细信息。
ASP.NET
在共享托管已成为 .NET 4.5 的 ASP.NET 团队的两个主要性能目标的情形下，可改进站点密度（又定义为“每站点内存消耗”）和缩短站点的冷启动时间。
在 ASP.NET 中，这是网站接收并响应请求所需的时间，即工作进程关闭时与网站编译完成时。
使用的功能包括：
- 默认情况下，ASP.NET 会为 Bin 文件夹程序集打开此功能，以便能够在站点启动和运行时继续更新 DLL。
- 通常将旨在供 ASP.NET 站点使用的预先打包的应用程序安装到 Bin 文件夹，而不是全局程序集缓存中。
- 共享托管方现在可以根据 ASP.NET 指南设置其计算机，以便最大限度地获得性能优势。
- 您可以在 web.config 文件中使用以下设置来禁用此功能：
<configuration>
<!-- ...
-->
<system.web>
<compilation profileGuidedOptimizations="None" />
<!-- ...
-->
- 要为高密度 Web 托管启用预取器，请在命令行中运行以下一组命令：
sc config sysmain start=auto
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 2 /f
reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher" /v MaxPrefetchFiles /t REG_DWORD /d 8192 /f
net start sysmain
- 您稍后可以更新 web.config 文件以在 ASP.NET 中使用它：
<configuration>
<!-- ...
-->
<system.web>
<compilation enablePrefetchOptimization
="true" />
<!-- ...
-->
- 若要启用 GC 优化，可在 Windows\Microsoft\v4.0.30319 文件夹的 aspnet.config 文件中选择 HighDensityWebHosting 设置，以便每个站点消耗更少的内存（工作集）：
<configuration>
<!-- ...
-->
<runtime>
<performanceScenario
value="HighDensityWebHosting" />
<!-- ...
-->
bit.ly/A66I7R 上的“ASP.NET 新版本入门”白皮书中找到有关 ASP.NET 性能改进的更多详细信息。
需要反馈
在您下载并尝试 .NET Framework 4.5 和 Visual Studio 11 Beta for Windows 8 后，如有关于未来版本的任何反馈或建议，请将您的想法告诉我们。
术语表
此技术大大降低了网站所有者的进入门槛。
对于大型应用程序，冷启动可能需要几秒钟，因为内存中不存在所需页面（代码、静态数据、注册表等），而将这些页面加载到内存中需要进行费时的磁盘访问。
这就是应用程序在您第二次运行它时启动速度更快的原因（或者第二个 .NET 应用程序比第一个启动更快的原因，因为 .NET 的部分内容已加载到内存中）。
当本机映像可用时，运行库会加载这些映像。
例如，CLR 对本机程序集（C++ 配置文件导引优化）和托管程序集（使用 MPGO）执行配置文件导引优化。
msdn.microsoft.com/magazine/dd882521。
压缩堆的主要目的是使更大的内存块可用于分配更多对象。