Oco*_*nel 7 delphi performance twebbrowser
有人可以解释一下为什么TWebBrowser控件在包括XE5和可能的XE6在内的所有XE版本的Delphi上都运行得如此之慢？要测试这个,你需要创建一个新的Delphi项目并将TWebBrowser控件放入其中.在表单显示事件中,导航到此网站:
http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
请在Windows 7或更高版本上测试.导航完成后,运行setImmediate test并观察结果.完成测试需要花费大量时间.完成此操作大约需要一分钟.
当你打开真正的Internet Explorer浏览器并做同样的事情 - 测试将立即完成(约200毫秒).
一些额外的奇怪信息:
当您在旧版本的Delphi(准确地说是Delphi 7)上重新创建此过程时,Web控件的工作速度应尽可能快,并且测试立即完成.但是HTML5速度测试仍然会很慢(本页的替代测试).
另一个奇怪的事情是,在C++ Builder中可以看到相同的缓慢行为,但在Visual Studio产品中却看不到.微软是否故意放慢Embarcadero产品中的TWebBorwser？我不能相信这一点.
我试图用不同的方法克服这个问题,例如:
在注册表中尝试不同的功能选项,例如:FEATURE_GPU_RENDERING,FEATURE_BROWSER_EMULATION(11001),FEATURE_ALIGNED_TIMERS(未记录的选项),FEATURE_ALLOW_HIGHFREQ_TIMER(未记录的选项),
设置timerBeginPeriod(1) - 没有效果.
如果有人知道如何解决这个问题,请与我分享这些信息.
UPDATE1 如果有人关心,我制作了独立的测试应用程序.它可以在这里下载:http://mp.org.pl/download/ietest.zip它包含带有htm文件的源和exe应用程序.HTM文件包含一些js过程,它在独立IE中比在TWebBrowser控件中快10倍.它使用setImmediate作为测试(与上述测试中使用的相同的过程).但是以这种方式测试会更容易.
我还可以看到所描述的行为（在您的原始帖子和评论中）。我有一些想法，但不一定有答案。
人们应该预料到 WebBrowser 控件和 IE 之间的性能存在一些差异，部分原因是您的 Delphi 应用程序需要构建对 IE 开箱即用的某些功能/API 的支持。
例如，WebBrowser 控件会触发与选项卡式浏览相关的通知（旧的，但相关），但它本质上并不处理这些通知或更新 UI。您必须响应通知并自己绘制选项卡。默认情况下，IE 是硬件加速的，并使用某些 Windows API，但 Delphi 的 VCL（出于资源/性能）原因可能不直接支持这些 API。（硬件加速可以解释您注意到的一些性能差异。）
（而且，郑重声明，我不认为 IE 和 WebBrowser 控件之间的差异列表曾经被记录在案。我当然不记得在产品组合中看到过这样的差异。）
此外，各种功能控件的默认值在 IE 和托管 WebBrowser 控件的应用程序之间有所不同。部分原因源于这样的想法：IE 需要强调性能而不是兼容性，而应用程序通常需要强调兼容性而不是性能。您可能希望查看功能控制参考，看看是否需要为您的应用程序启用其他 FCK。
其次，你的循环非常紧，也许太紧了。您的一个请求堆积在较早的请求上，并且即使使用 setImmediate，您也没有真正留下太多处理空间。（IIRC，我们实际上不应该在 setInterval 中使用任何小于 250ms 的值，否则会冒着因请求数量过多而导致性能下降的风险。）setImmdiate参考文献中的注释。页面提供了一些指导，就像这篇关于requestAnimationFrame的文章一样。
拖动窗口似乎可以提高性能的原因之一可能是由于窗口拖动重绘请求的优先级。它们可能会迫使您的循环保持足够长的时间（甚至中断）以允许其他事件处理。很难说没有使用调试器跟踪系统。
您是否曾经需要将 application.processMessages() 添加到您的 Delphi 应用程序中，以便让系统有机会处理您已经分配的工作？鉴于您的测试的性质，类似的需求可能会发挥作用。
性能测试和计时是一件棘手的事情。您需要确保测试不会造成太多开销，以免干扰您尝试执行的实际工作。
最后，当页面加载到项目中时，存在一些关于页面文档模式的问题。当我第一次开始摆弄你的示例时，我无法让project4以IE5怪异模式（众所周知的慢）以外的任何方式加载slowtest.html。这最终开始为我工作：
<!DOCTYPE html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<script type="text/javascript">
...
（请注意，我删除了您的初始文档类型声明并重写它以解决 F12 工具调试器报告的语法错误。）
这里有一些风格要点：
我使用了网络标记来加载 Internet 区域中的页面。我发现这使得在边缘模式下加载页面变得更容易，因为默认情况下，Intranet 区域中的页面会在兼容性视图中加载（除非您以不同的方式映射区域）。
x-ua 兼容标头需要是标头块中的第一个标头之一。它可以跟在标题后面，但不能有太多其他内容。
从风格上来说，如今元素需要以小写形式指定。不遵循当前约定可能会迫使解析器回退到支持约定的早期渲染。
一旦我能够在运行时控制 documentMode，我就发现了预期的结果：旧的文档模式运行得更慢。我还发现使用 requestAnimationFrame 而不是 setImmediate 可以获得更好的性能，但也几乎立即出现了计时问题。
最后，这可能是测试突出显示问题的情况，但不一定是您想要解决的问题。（在此处插入 Inigo meme。）我知道您正在尝试解决瓶颈。您确定找到了正确的瓶颈吗？
您可能无法复制本机浏览器的相同性能，但也许您可以重构代码以充分执行而不需要额外的开销？有什么事情可以通过工作人员或其他实现技术更好地处理吗？
希望这可以帮助...