/ CLR编译：从DLL调用虚函数时速度慢125倍？ [英] /CLR Compilation: 125x slower when calling virtual function from DLL?
问题描述
问候！我已经将Builder的应用程序移植到VS .NET 2003和
搜索可能的瓶颈（应用程序当前正在运行
慢）。
我发现一个场景，当使用/ CLR参数编译DLL然后编译时，测试函数需要125倍的时间来执行
执行
没有它。
平均时间：
----------------------- ------
编译/ CLR：18879
编译时没有/ CLR：151
生成器：420
当我调用函数
" CallTheFunctionAndBenchmark（）"时，会出现* *巨大*差异。来自这个DLL（下面还有更多）：
..h
#ifdef DRAWDLL_EXPORTS
#define DRAWDLL_API __declspec（dllexport ）
#else
#define DRAWDLL_API __declspec（dllimport）
#endif
class DRAWDLL_API CDrawDll {
public：
CDrawDll（void）;
void CallTheFunctionAndBenchmark（void）;
virtual int * gimmeAnInt（无效）;
int number;
}
..cpp：
#include" stdafx.h"
#include" DrawDll.h"
#include< stdio.h>
BOOL APIENTRY DllMain（HANDLE hModule，
DWORD ul_reason_for_call，
LPVOID lpReserved
）
{
返回TRUE;
}
CDrawDll :: CDrawDll（）
{
number = 7;
return;
}
void CDrawDll :: CallTheFunction（void）
{
int * ptrReceive;
__int64 m_ElapsedTime;
DWORD m_Retval;
LARGE_INTEGER m_StartCounter; //开始时间
LARGE_INTEGER m_EndCounter; //完成时间
//开始配置文件
m_Retval = QueryPerformanceCounter（& m_StartCounter）;
/// - -------------------------------------------------- -------------
//10.000调用函数...
for（int i = 0; i< 10000; i ++）
{
ptrReceive = gimmeAnInt（）;
};
// ----------------------------------------------- -------------------
//结束资料
m_Retval = QueryPerformanceCounter（& m_EndCounter）;
//获取并存储完成时间和计算经过时间（刻度）
m_ElapsedTime =（m_EndCounter.QuadPart - m_StartCounter.QuadPart）;
char buff [255];
sprintf（buff，"％I64d \ n"，m_ElapsedTime）;
OutputDebugString（buff）;
//为了避免编译器优化分析代码，请阅读数据
sprintf（buff，" nr：％d \ n"，* ptrReceive）;
Out putDebugString（buff）;
};
int * CDrawDll :: gimmeAnInt（void）
{
返回& number;
};
一个奇怪的事实是，如果调用的虚函数来自同一个
模块（例如，在Form本身中定义的一个函数）这不会发生
发生......事情进展得很快！ Windows Forms Executable是/ CLR by
定义。只有当函数在DLL中时才会发生这种情况。
我知道CLR编译应该花费更长时间，但*这个*更长？
我的程序很难使用属性（__declspec（属性（get =
GetXX ...），其中大部分基于虚函数调用。
程序是模块化的（DLL）。
为什么会发生这种情况？有没有办法可以避免这个瓶颈？
谢谢你关于这个问题的任何帮助/澄清！
我的意思是我知道CLR编译需要更长的时间，但*这个*更长？
实际上是
我知道CLR编译的代码应该花费更长的时间，但*这个*更长？
Fabro
您好Gustavo L. Fabro，
我发现一个场景需要一个测试功能125倍以上
我有几乎相同的问题...也许它与您的相关：
请参阅：
http://groups.google.de/groups?selm=...almbachholzma%
40127.0.0.1
-
问候
Jochen
关于Win32和.NET的博客
http://blog.kalmbachnet.de/
< blockquote>感谢您的回复。我已经验证这是Everett
编译器的一个问题，但这在beta1 whidbey中得到修复。您可以从
msdn.microsoft.com/visualc下载beta1。
谢谢，
Kapil
" Jochen Kalmbach"写道：
您好Gustavo L. Fabro，
我发现一个场景需要125倍的测试功能
在使用/ CLR参数编译DLL时执行，然后在没有它的情况下进行编译。
我有几乎相同的问题...也许它与你的相关：
请参阅：
http：// groups.google.de/groups?selm=...almbachholzma%
40127.0.0.1
-
问候
Jochen
我关于Win32和.NET的博客
http：//blog.kalmbachnet。 de /
Greetings! I''ve been porting an application for Builder to VS .NET 2003 and
searching for possible bottlenecks (the application is currently running
slow).
I found out one scenario that takes a test function 125x more time to
execute when the DLL is compiled with the /CLR parameter then when compiled
without it.
Average timings:
-----------------------------
Compiled with /CLR: 18879
Compiled without /CLR: 151
Builder: 420
This *huge* difference appears when I call the function
"CallTheFunctionAndBenchmark()" from this DLL (there is more below):
..h
#ifdef DRAWDLL_EXPORTS
#define DRAWDLL_API __declspec(dllexport)
#else
#define DRAWDLL_API __declspec(dllimport)
#endif
class DRAWDLL_API CDrawDll {
public:
CDrawDll(void);
void CallTheFunctionAndBenchmark(void);
virtual int* gimmeAnInt(void);
int number;
}
..cpp:
#include "stdafx.h"
#include "DrawDll.h"
#include <stdio.h>
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
CDrawDll::CDrawDll()
{
number = 7;
return;
}
void CDrawDll::CallTheFunction(void)
{
int* ptrReceive;
__int64 m_ElapsedTime;
DWORD m_Retval;
LARGE_INTEGER m_StartCounter; // start time
LARGE_INTEGER m_EndCounter; // finish time
//Start profile
m_Retval = QueryPerformanceCounter (&m_StartCounter);
///-----------------------------------------------------------------
//10.000 calls to the function...
for(int i=0;i<10000;i++)
{
ptrReceive = gimmeAnInt();
};
//------------------------------------------------------------------
//End profile
m_Retval = QueryPerformanceCounter (&m_EndCounter);
// get and store finishing time and calc elapsed time(ticks)
m_ElapsedTime = (m_EndCounter.QuadPart - m_StartCounter.QuadPart );
char buff[255];
sprintf(buff, "%I64d\n", m_ElapsedTime);
OutputDebugString(buff);
//To try to avoid compiler from optimizing profiling code, read the data
sprintf(buff, "nr: %d\n", *ptrReceive);
OutputDebugString(buff);
};
int* CDrawDll::gimmeAnInt(void)
{
return &number;
};
One curious fact is that if the virtual function called is from the same
module (for instance, a function defined in the Form itself) this does not
happen... The thing goes fast! And the Windows Forms Executable is /CLR by
definition. this only happens when the function is inside a DLL.
I know CLR compilation is supposed to take longer, but *this* longer?
My program makes hard use of properties (__declspec( property( get =
GetXX...), and most of them are based on virtual functions calls. And the
program is all modularized (DLLs).
Why does this happen? And is there a way I can avoid this bottleneck?
Thanks for any help/clarification on this issue!
What I meant withI know CLR compilation is supposed to take longer, but *this* longer?
is actually
I know CLR compiled code is supposed to take longer, but *this* longer?
Fabro
Hi Gustavo L. Fabro,
I found out one scenario that takes a test function 125x more time to
execute when the DLL is compiled with the /CLR parameter then when
compiled without it.
I had almost the same problem... maybe it is related to yours:
See:
http://groups.google.de/groups?selm=...almbachholzma%
40127.0.0.1
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Thanks for your reply. I have verified that this is an issue with the Everett
compiler but this is fixed in beta1 whidbey. You can download beta1 from
msdn.microsoft.com/visualc.
Thanks,
Kapil
"Jochen Kalmbach" wrote:
Hi Gustavo L. Fabro,I found out one scenario that takes a test function 125x more time to
execute when the DLL is compiled with the /CLR parameter then when
compiled without it.
I had almost the same problem... maybe it is related to yours:
See:
http://groups.google.de/groups?selm=...almbachholzma%
40127.0.0.1
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
这篇关于/ CLR编译：从DLL调用虚函数时速度慢125倍？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
