Re: /CLR Compilation: 125x slower when calling virtual function fr
From: Kapil Khosla [MSFT] (kkhosla_at_online.microsoft.com)
Date: 01/25/05
- Next message: sujeeshlal: "dll removing tool"
- Previous message: one2001boy_at_yahoo.com: "Re: execv hanged"
- In reply to: Gustavo L. Fabro: "Re: /CLR Compilation: 125x slower when calling virtual function fr"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 24 Jan 2005 21:36:25 -0800
> 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" <gustavo_fabro%remove_this%@hotmail.com> wrote in message
news:35l7rtF4ojph5U1@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
> gustavo_fabro%removethis%@hotmail.com
>
>
- Next message: sujeeshlal: "dll removing tool"
- Previous message: one2001boy_at_yahoo.com: "Re: execv hanged"
- In reply to: Gustavo L. Fabro: "Re: /CLR Compilation: 125x slower when calling virtual function fr"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
