473,325 Members | 2,805 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

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


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!
Nov 17 '05 #1
10 2057
What I meant with
I 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
Nov 17 '05 #2
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/
Nov 17 '05 #3
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/

Nov 17 '05 #4
Please let me know if you need help getting beta1 whidbey compiler.
Thanks,
Kapil

"Gustavo L. Fabro" <gu************************@hotmail.com> wrote in message
news:35*************@individual.net...
What I meant with
I 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

Nov 17 '05 #5
Hi =?Utf-8?B?a2tob3NsYQ==?=,
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.


This is nice to know but does not help!
We are shipping our product since release of VS2003.
And we cannot switch to an beta-product or to an later release, because we
*must* maintain our shipped environment (.NET1.1)!

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Nov 17 '05 #6
> 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

Thanks for the comments. I've downloaded whidbey beta 1 (Visual C++ 2005
Express Edition Beta) and run the same tests. After a few teaks to compile
the test properly, things indeed worked much better:

Timings:

Visual C++ 2005 Beta 1
----------------------------
With /CLR : 495
Without /CLR: 382

Visual C++ .NET 2003
----------------------------
With /CLR: 18879
Without /CLR: 151
Borland Builder 5.0 (for comparison)
----------------------------
Builder: 420

Any clues as to when will the final version of VS 2005 be available?

And as Jochen well said, unfortunately this doesn't solve the problems of
current projects...
Any chances of a service pack to fix such issue on 2003 or it's a big change
and will only be available on whidbey?

Thanks

Gustavo Fabro
gu***********************@hotmail.com
Nov 17 '05 #7
Gustavo L. Fabro wrote:
Any clues as to when will the final version of VS 2005 be available?


Beta 2 could be as soon as 5-6 weeks, according to certain hints:
http://www.stillhq.com/aus-dotnet/ar.../msg00002.html

The good news is that it's expected to be very stable, and with a
go-live license, which means we will be able to distribute our code
compiled with it. I hope that's true.

Final version? Its date is not announced yet.

Tom
Nov 17 '05 #8
> And as Jochen well said, unfortunately this doesn't solve the problems of
current projects...
Any chances of a service pack to fix such issue on 2003 or it's a big
change and will only be available on whidbey?


Sure. I think I can give you a workaround for it in everett.

From your code

#include <time.h>
#include <stdio.h>
/*******Note the pragma unmanaged *******/
#pragma unmanaged
class MyTest1
{
private:
int s_i;
virtual void Test1(int i)
{
s_i += i;
}

public:
void MakeTest()
{
clock_t start, finish;
double duration;

start = clock();
for(int i = 0; i< 10000000; i++)
{
Test1(i);
}
//EndTimeMeasure();
finish = clock();
duration = (double)(finish - start) / (CLOCKS_PER_SEC);
printf( "%2.1f seconds\n", duration );

}
};

int main()
{
MyTest1 obj;
obj.MakeTest();
}

When you compiled your native class with /clr, it causes what is called
double thunking. A call is made from a managed call site to a mangaged
function definition via a native vtable.

Yes, that is right. The vtable is native in this case so there is
performance penalty when you make a transition from managed - native and
native - managed. When I applied #pragma unmanaged over the function
definition, I reduce the thunking from native to managed and thus saved the
performance penalty. On my everett compiler this code took .4 seconds vs
13.5 seconds if I dont use #pragma unmanaged.

Please let me know if this fixes your problem.

Thanks, Kapil

"Gustavo L. Fabro" <gu************************@hotmail.com> wrote in message
news:35*************@individual.net...
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

Thanks for the comments. I've downloaded whidbey beta 1 (Visual C++ 2005
Express Edition Beta) and run the same tests. After a few teaks to compile
the test properly, things indeed worked much better:

Timings:

Visual C++ 2005 Beta 1
----------------------------
With /CLR : 495
Without /CLR: 382

Visual C++ .NET 2003
----------------------------
With /CLR: 18879
Without /CLR: 151
Borland Builder 5.0 (for comparison)
----------------------------
Builder: 420

Any clues as to when will the final version of VS 2005 be available?

And as Jochen well said, unfortunately this doesn't solve the problems of
current projects...
Any chances of a service pack to fix such issue on 2003 or it's a big
change and will only be available on whidbey?

Thanks

Gustavo Fabro
gu***********************@hotmail.com

Nov 17 '05 #9
Kapil,
Sure. I think I can give you a workaround for it in everett.
/*******Note the pragma unmanaged *******/
#pragma unmanaged
class MyTest1 <snip>
When you compiled your native class with /clr, it causes what is called
double thunking. A call is made from a managed call site to a mangaged
function definition via a native vtable.

Yes, that is right. The vtable is native in this case so there is
performance penalty when you make a transition from managed - native and
native - managed. When I applied #pragma unmanaged over the function
definition, I reduce the thunking from native to managed and thus saved
the performance penalty. On my everett compiler this code took .4 seconds
vs 13.5 seconds if I dont use #pragma unmanaged.
Hmmmm that's why!
Please let me know if this fixes your problem.


In the testing scenario it indeed solved the issue. It will require some
work to
add the #pragma directive to the 1.119 cpp files and correspondent .h files
but, heck, what are trainees for, anyway? ;)

In the background I'm compiling my code in VS 2005 to see if that alone was
the
big performance issue or if anything new comes up. On any case I will post
the
results later...

Thanx!

Gustavo Fabro
gu***********************@hotmail.com
Nov 17 '05 #10
If all your cpp files start with #include "stdafx.h" you could use the visual
studio replace in files to add "#pragma unmanaged" before it automatically
rather than editing a thousand files.

"Gustavo L. Fabro" wrote:
Kapil,
Sure. I think I can give you a workaround for it in everett.
/*******Note the pragma unmanaged *******/
#pragma unmanaged
class MyTest1

<snip>
When you compiled your native class with /clr, it causes what is called
double thunking. A call is made from a managed call site to a mangaged
function definition via a native vtable.

Yes, that is right. The vtable is native in this case so there is
performance penalty when you make a transition from managed - native and
native - managed. When I applied #pragma unmanaged over the function
definition, I reduce the thunking from native to managed and thus saved
the performance penalty. On my everett compiler this code took .4 seconds
vs 13.5 seconds if I dont use #pragma unmanaged.


Hmmmm that's why!
Please let me know if this fixes your problem.


In the testing scenario it indeed solved the issue. It will require some
work to
add the #pragma directive to the 1.119 cpp files and correspondent .h files
but, heck, what are trainees for, anyway? ;)

In the background I'm compiling my code in VS 2005 to see if that alone was
the
big performance issue or if anything new comes up. On any case I will post
the
results later...

Thanx!

Gustavo Fabro
gu***********************@hotmail.com

Nov 17 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Mark Broadbent | last post by:
I think I know the outcome to this question (please forgive me because I know it is probably asked a thousand times!) Does Microsoft plan to bring out some kind of mechanism to compile directly...
7
by: seema | last post by:
hi all , I am new to C++ programming. Can some body explain reason for this compilation error, .../inc/polecache.h", line 339: error #2322: object of abstract class type...
11
by: ypjofficial | last post by:
Hello All, So far I have been reading that in case of a polymorphic class ( having at least one virtual function in it), the virtual function call get resolved at run time and during that the...
7
by: Markus Svilans | last post by:
Hello, My question involves virtual functions and inheritance. Suppose we have a class structure, that consists of "data" classes, and "processor" classes. The data classes are derived from...
35
by: mwelsh1118 | last post by:
Why doesn't C# allow incremental compilation like Java? Specifically, in Java I can compile single .java files in isolation. The resulting individual .class files can be grouped into .jar files....
1
by: newbie | last post by:
This is a snippet from C++ FAQs, which I have never done--- when I do such a thing, I would declare function used by constructor ( in this example, init() ) as static. But I do understand that it...
1
by: BSand0764 | last post by:
I'm getting an error that I can't seem to resolve. When I compile the Functor related logic in a test program, the files compile and execute properly (see Listing #1). However, when I...
82
by: raashid bhatt | last post by:
is there any standards that tell us how c code has to be compiled into machine code
5
by: want.to.be.professer | last post by:
For OO design, I like using virtual member function.But considering efficiency, template is better. Look at this program, class Animal { public: virtual void Walk() = 0; }; class Dog
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.