/CLR Compilation: 125x slower when calling virtual function from DLL?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Gustavo L. Fabro (gustavo_fabro%remove_this%_at_hotmail.com)
Date: 01/21/05 

Date: Fri, 21 Jan 2005 11:58:59 -0300

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!

Relevant Pages

  • /CLR Compilation: 125x slower when calling virtual function from DLL?
    ... searching for possible bottlenecks (the application is currently running ... "CallTheFunctionAndBenchmark" from this DLL: ... virtual int* gimmeAnInt; ... I know CLR compilation is supposed to take longer, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Problem with constants (MSVC)
    ... h79 wrote: ... >is the same as (after compilation): ... int main ... Fixing this could break clients of the DLL who also use the ...
    (microsoft.public.vc.language)
  • Re: Forwarding DLL
    ... int add; ... This is compiled as static lib, and nothing of this is marked as ... nothing was exported from the DLL and so there is nothing to satisfy ... because it wasn't told to do so during compilation. ...
    (microsoft.public.vc.language)
  • error LINK2019: unresolved external symbol
    ... some use as parameter of the int, other CString. ... During the compilation of the DLL I don't have errors. ...
    (microsoft.public.vc.mfc)
  • Re: What is a type?
    ... >> compilation time. ... The type int is perfectly supported by ... You probably won't find the term "int" in a CPU reference manual. ... I meant that a function pointer could be implemented as an index into ...
    (comp.lang.c)